>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:

        - keyboard
        - mouse

        - screen

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


Reply via email to