William Young wrote:
> Darren J Moffat wrote:
>> William Young wrote:
>>
>>> Multiple X servers and a gui switch event is an interesting problem.  
>>> It will be necessary to disable the possibility of any single label X 
>>> sessions or one can visually emulate the switcher with trusted path.  
>>> I don't think that is a concern right now, but should be a noted 
>>> requirement if a secure X switcher is mentioned.
>>
>>
>> I think that concern is there regardless of a GUI for doing the 
>> switching.  If a keyboard (or any other method, eg programatic) 
>> switching is possible that can be used to spoof as well (and in fact 
>> is probably even more risky in some cases).
>     The write up included disabling keyboard methods and multiple VTs 
> generally but mentioned the possibility of a secure gui switcher to have 
>  multiple graphics/X VTs only.  This could be done securely, but only if 
> all available graphic sessions are trusted (so the gui can have trusted 
> path and there is no means to falsely create the appearance of trusted 
> path.)
>     Keyboard mechanisms could be acceptable but keyboard events would 
> have to be going to a VT manager for initial processing and in TX's case 
> I think we would require a part of VT management to handle session 
> locking etc.  The VT management would also need to do something visual 
> and non-forgeable to indicate when the sequences were hit to prevent 
> simple physical attacks (i.e. physically damaging a key in the sequence 
> and then emulating the VT change.)

Which says to me that what Solaris really needs here is a Trusted Path 
that is graphical and available via a secure attention key sequence that 
is implemented in the kernel and not as part of the desktop environment/ 
Xserver like it is today (and always was in Trusted Solaris and SunOS CMW).

That however is out of scope for this project team but I believe they 
aren't doing anything that our impact us doing a kernel based trusted 
path in the future.

>> I think though you have pointed out the best behaviour from the TX 
>> view which is that if the system is labeled the vt's are not enabled - 
>> or at least they can't be allowed to enter a graphics mode.  IIRC in 
>> previous Trusted Solaris releases we actually disabled the dtlogin 
>> "Command Line Login" option but we don't in TX (which I'm okay with).
>>
> Yes, I think there may be a race condition that allows X/cdelogin to 
> start when there is an active command line session which should be 
> fixed.  Being able to do either-or seems fine to me as well.

The fix IMO is the replacement of dtlogin with gdm which doesn't have 
this issue best I can tell.

-- 
Darren J Moffat

Reply via email to