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.)
>
> 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.
-Will
