Message: previous - next
Month: April 2012

Re: [trinity-devel] Latest tsak patch report (GIT hash 6cfb160)

From: Darrell Anderson <humanreadable@...>
Date: Sat, 21 Apr 2012 23:34:42 -0700 (PDT)
> >  * Glitch: KControl is not displaying the check
> box as enabled despite useSAK=true. Probably a forgotten or misplaced
> readEntry?
> This behaves that way on purpose--when useSAK=true and tsak
> cannot be enabled (i.e. when uinput is not loaded) the checkbox is not
> checked to avoid the appearance of tsak being permanently
> enabled.  If this is confusing then we will need to find a better way to indicate
> this.

I did not explain myself well. After I loaded uinput and set useSAK=true the check box was not showing enabled. The check box did not show the correct status thereafter. The check box was always showing disabled, contrary to useSAK=true and uinput=loaded. Everything was working as I described, just the check box did not show the correct status.

I expect the check box to be ghosted when uinput is not loaded regardless of the status of useSAK, along with the warning message, and that all works.

> >  * Possible glitch: Seems TDM should restart tsak as soon as I logged in,
> > despite my "malevolent" effort to disable tsak. However, as shown by the
> > Switch User test, TDM immediately restarted tsak, and that probably is
> > sufficient. Within the intent of how tsak should function (I don't know
> > the specs), I'm unsure whether TDM should be polling the process list to
> > immediately restart tsak when disabled as I circumvented. Seems to me
> > that a user should not be able to do what I did. Even if I did not have a
> > free console open, I could have accomplished the same with through SSH.
> > Seems to me that as long as useSAK=true tsak should be a persistent
> > little b-stard. :)
> I never really thought about this, but I guess this might be
> a correct way of looking at it.  My original thought was that if
> someone killed tsak, all users would know that the system was compromised as the
> Ctrl+Alt+Del screens would not appear or function.  Automatically
> restarting tsak might make more sense, but TDE's design doesn't make this
> particularly easy.

I had not thought about that either. I suppose in any environment where sak was deemed necessary, there would be training that the dialog should always appear and when that does not happen to report to an admin. In such an environment, I doubt a single console would be open to have such access as I have on mine. If SSH was available in that environment then likely keys and passphrases both would be used, so pretty tough to hack tsak. Ignoring those oddball corner cases then means tsak is working as intended.

Ok, forget that. The check box needs to reflect the correct status after everything is enabled. Otherwise this patch is in the bag.