>I believe that makes it worse because now you have the
>potential for them both to be trying to use the device
>at the same time.
The more I think of this the more it seems we need some
form of generic device multiplexing layer.
The devices we are multiplexing are:
input:
- keyboard
- mouse
output:
- screen
input/output
- audio
For now, it seems that the only thing we deal "properly" with is
the "screen".
Security does not allow sharing of any of the input devices (keyboard,
mouse, audio) but because multiple sessions coexist we cannot
revoke the access, even if we had the mechanism to do so.
For keyboard/mouse, there are some proposed solutions:
- prevent output when session mismatches
- revoke access currently given through /etc/logindevperm and
trust Xorg/Xsun not to read from the devices.
where the second solution has some clear advantages (ease of implementation)
For the audio device, this is much more difficult:
- device allocation does not solve this because it only gives
one concurrent user access and it calls 'fuser -k' on
running processes in other sessions
- Windows is also broken as it allows all sessions to continue
to stream output (as far as I can tell); is this something we
want to emulate (well, Darren said he liked playing iTunes in
one account while doing something else in another account, yet
this seems wrong on general principle to me)
- the input of the audio device (eaves dropping, who remembers
the "rsh hostname cat /dev/audio" scare??
This sort-of screams for a "session aware" audio mixer.
There is, of course, another solution: PUNT.
Just assume that it's always the same physical user who is using
different sessions so leakage is not an issue. But if this is
acceptable, then we must have a secure attention key:
- KILL ALL VT SESSIONS using a key sequence which cannot be
disabled by programs, revoking all session I/O devices and
resetting all ACLs, giving a clean "/dev/console" login.
Such a secure attention key combination is long overdue anyway, but....
As all of the affected devices are STREAMs devices, a generic "itsmine"
streams module (unpoppable) may suffice.
This does require the keyboard/mouse opens to be clone opens which
duplicate output to all processes opening it.
(So "cat /dev/mouse" will no longer steal mouse input but will rather
mirror it)
Casper
