The following is the proposal for secure hotkeys for virtual console
switch. Any comment is welcome.



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

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

        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.

Reply via email to