Hi,
The following is the proposal for secure hotkeys for virtual console
switch. Any comment is welcome.
Riny
=======================================
1. Background
Presently with virtual console, there're multiple console sessions
and probably multiple X/Graphical sessions running at the same
time, looking as following:
| console | console | | X/Graphical | X/Graphical | |
| session #1 | session #2 | | session #1 | session #2 | |
| | | | | | |
| /dev/console | /dev/vt/2 | ... | /dev/vt/7 | /dev/vt/8 | ... |
| | | | | | |
| system | virtual | | Xserver | Xserver | |
| console | console | | | | |
Console sessions are provided by the system/console-login SMF
service. By default, there are six service instances. The first
one is system/console-login:default for the system console (also
known as virtual console #1) running on /dev/console. The others
are system/console-login:vt# for other virtual consoles (sessions)
running on /dev/vt/# (# is 2 to 6). Users can use "Alt + F#" to
switch between these console sessions. Here the hotkeys are
intercepted by the kernel console driver. And the active (virtual)
console session gets the actual I/O (keyboard/screen).
By default, there's only one Xserver (graphical session) provided
by graphical-login/cde-login or graphical-login/gdm SMF service.
Users can configure /etc/dt/config/Xservers for dtlogin or
/etc/X11/gdm/custom.conf for GDM to run multiple Xservers
(graphical sessions), or use gdmflexiserver utility with GDM to
start other Xservers (graphical sessions) on demand. Each Xserver
gets a virtual console for its controlling tty. By default,
/dev/vt/7 is for the first (usually only) one Xserver (graphical
session). Users can use "Alt + Ctrl + F#" to switch between
Xservers (graphical sessions). Here in the Xserver (Xorg), the
hotkeys are intercepted by Xserver (Xorg) itself, and the active
Xserver (graphical session) gets the actual I/O (keyboard input
and graphical screen output). In Xservers (graphical sessions),
users can aslo use gdmflexiserver to switch to other graphical
sessions presently if gdm is being used as the display manager
instead of dtlogin.
From any console session to any Xserver (graphical session), it's
"Alt + F#" (# is the number of the Xserver's controlling tty)
because at the moment the hotkeys are intercepted by the kernel
console driver. From any Xserver (graphical session) to any
console session, it's "Alt + Ctrl + F#" (# is the number of the
console session's controlling tty).
At a time, there's only one active session (console session or
graphical session), which gets the I/O.
2. Problem
There is a security issue with the switching between different
users' sessions (console sessions or graphical sessions), for
example, a normal user may switch to and get access to a
root's unlocked session.
Presently users can lock their sessions before they leave off
their sessions if they are seriously concerned about their
sensitive information. But it's not perfect, and the ideal
solution is that the password for the switched-to target session
is automatically prompted for before switching to a different
user's session (like on Mac OS X).
Currently GDM/gdmflexiserver can provide such similar
functionality, but it's only for graphical sessions and GDM is
not the default display manager either.
3. Solution
3.1 Definitions
Console session:
Text based command line session provided by console-login
SMF service. ttymon(1M) will provide the console login
prompt. Once a user logs in, normally a shell will work
for each console session.
Xserver/Graphical session:
Graphics based window session provided by graphical-login
SMF service. Each Xserver (Xorg) will work for a graphical
session. The display manager (dtlogin or GDM) will provide
the graphical login screen.
Owner of console session:
The owner of a console is the user who initially logs into
it. The su, sudo, or any setuid program running in the
session will not change the ownership of the session. If
there's no one logged in onto a session, the owner of that
session is none (so that anyone can switch to).
Owner of graphical session:
The owner of all graphical sessions is none, since the
graphical session gets automatically locked once switching
away.
3.2 vtdaemon
There is a vtdaemon, who is responsible for the session
switch via hotkeys. It has the appropriate privileges to
issue the actual virtual console session switch.
The vtdaemon self is, like ttymon(1M), also running on a
virtual console device (/dev/vt/#), and provides a console
session for password input and authentication. Users cannot
switch to this special console session via hotkeys, and
actually there's no hotkeys for this purpose. And the owner
of this special console session is none.
All console hotkeys ("Alt + F#") are intercepted by the
kernel console driver which sends a door upcall to the
vtdaemon:
door_upcall (to_vt, -1, 0).
All Xorg hotkeys ("Alt + Ctrl + F#") are intercepted
by Xorg which sends a door call to the vtdaemon:
door_call (to_vt, displaynumber, logged-in).
There's a system/vt-switch:default SMF service for this
vtdaemon.
There's a "hotkeys" property (BOOLEAN) in the
system/vt-switch:default SMF service, which allows authorized
users to dynamically enable or disable VT switch via hotkeys.
Its default value is TRUE (enabled).
There's a "secure" property (BOOLEAN) in the
system/vt-switch:default SMF service, which allows authorized
users to dynamically enable or disable hotkeys are secure.
If disabled, the user can freely switch to any session without
authentication. Its default value is TRUE (enabled).
There's a "rootunlock" property (BOOLEAN) in the
system/vt-switch:default SMF service, which allows authorized
users to dynamically enable or disable the root user can unlock
any sessions. Its default value is FALSE (disabled).
3.3 Behaviours
. The console text vtdaemon will prompt for password for the
target (console) session while switching from any (locked or
unlocked, logged-in or idle) console/graphical session to a
logged-in console session;
. The logged-in graphical session gets automatically locked
(xscreensaver, CDE built-in lock, or xlock) while switching
away. So it needs password while switching from any (locked
or unlocked, logged-in or idle) console/graphical session to
a logged-in graphical session.
(If the userA logs into a console session, and a graphical
session, he/she needs to input password while switching between
these two sessions, though the actual owner is the same.
Otherwise if the userA locks the graphical session and then
walks away, then other guys can switch to the userA's console
session without password.)
3.4 vtdaemon detail upon receiving hotkeys request
3.4.1 check if hotkeys for VT switch are disabled. If disabled,
ignore request.
3.4.2 check if "secure" is disabled. If disabled, directly issue
the VT switch.
3.4.3 check source session:
. query the active vt for the source session
if active_vt is equal to to_vt, ignore this quest.
. determine if it's a console/graphical source session
displaynumber == -1?: console session
Otherwise, graphical session
. If it's a graphical source session
i) check if the door call is really from Xorg process
otherwise, discard this request.
ii) if logged-in, activate screenlock for this source
graphical session
. If it's a console source session
check if the door call is from kernel.
otherwise, discard this request.
3.4.4 determine the owner of the target session (owner_target):
3.4.5 check the owner_target
. owner_target is none: actually issue the VT switch
. othewise:
i) firstly switch to the vtdaemon special text console;
ii) prompt for password (owner_target on to_vt);
E.g. "User Bob's password on vt#: ".
iii) the password is correct (authentication succeeds),
then actually issue the VT switch;
iv) the password is wrong, ignore the request.
3.5 Xorg change
. Upon starup, Xorg queries an available VT (usually /dev/vt/7
for the first one), and switches to itself, like today. It has
the privileges to issue the actual switch since it's setuid root
upon startup.
. Upon exit, Xorg simply sends a request, just like for the
hotkeys, to the vtdaemon to switch back to the previous active
session while Xorg was starting up.
4. Notes about GDM
The abovementioned solution is independent of GDM/gdmflexiserver.
And gdmflexiserver can still be used like today to switch between
graphical sessions in a secure way.
5. What we don't address
In Xserver (graphical session), when you su in a window terminal
and then change keyboard focus away to another window terminal,
you don't need to reauthenticate to reenter the su window terminal.
Likewise for changing CDE or GNOME virtual desktops/workspaces
within a single login graphical session.
Likewise in a console session, when you su or setuid in any
applications to someone (here you don't change the ownership of
this console session) and then switch to another session, you just
need to reauthenticate the owner instead of the su'ed user to
reenter that console session.
