On 25/06/14 20:03, Svante Signell wrote:
> On Wed, 2014-06-25 at 17:38 +0100, Simon McVittie wrote:
>> Upstream developers in various projects increasingly oppose group-based
>> access, because membership of many "desktop stuff" groups essentially
>> means "can ssh in and do bad things to a local user". For instance,
>> putting desktop users in group 'audio' or 'video' is no longer a
>> requirement for access to sound cards on systems with systemd-logind (it
>> hands out access using temporary ACLs instead) - which is just as well,
>> because putting those users in a group with permanent rw access to the
>> sound device or webcam would essentially mean they can ssh in while
>> someone else is using a computer, and spy on what is said near it.
>
> Couldn't this problems be solved by denying remote users desktop login,
> only by tty, and the only way to get to the desktop is with startx?
No. The root of the problem is that if a user is in a group, they are in
that group regardless of whether they logged in locally (getty, startx,
local X via gdm/xdm/..., etc.) or remotely (ssh, XDMCP, VNC, etc.). You
could think of the problem as being: the "plumbing" layer of the
operating system doesn't know whether it's appropriate for them to be
able to do 'normal desktop things' or not.
Concretely, suppose Alice and Bob share access to a machine (maybe a
shared computer-lab desktop, or a laptop). Alice is logged in locally,
and Bob logs in to it via ssh.
The group-based way: Alice and Bob need to be in group audio so they can
use the audio, video so they can use the webcam, and netdev so they can
interact with NetworkManager or equivalent. The audio and video device
nodes are crw-rw---- root:audio and root:video, so Bob can open those
device nodes for reading, so he can eavesdrop on Alice; and a
group-based policy in PolicyKit says he is allowed to interact with NM,
so he can annoy Alice by disconnecting from the network. There are
probably plenty more fun exploits like reading (or rewriting!) Alice's
removable media. Basically, full of badness.
The fractionally better group-based way: Alice and Bob are not in group
audio in /etc/group, but their processes are put in that group by a PAM
module or something. Bob logs in locally, finds a filesystem that is not
mounted nosuid where he can write files (yeah yeah nosuid, but in
practice there will usually be one), creates a copy of /bin/bash with
permissions -rwxr-s--- bob:audio or bob:netdev (as appropriate), and can
still do bad things to Alice later; also, D-Bus, and anything else that
looks up a uid's groups rather than a process's groups, doesn't believe
that he's in group netdev (in the case of D-Bus this is a longstanding
feature request, but turns out to be difficult to solve securely).
The better way: when Bob logs in to gdm (or equivalent), systemd-logind
(or equivalent) does something analogous to "setfacl -m user:bob:rw-
/dev/snd/*"; when he logs out, it does something analogous to "setfacl
-m user:bob:--- /dev/snd/*". While Alice is logged in, only she can
access those device nodes, and Bob can't. Meanwhile, the PolicyKit
policy controlling access to NetworkManager says "only the active
locally-logged-in user can mess with this".
(You're probably about to object "but what if Bob leaves processes
running with /dev/snd/* still open?" and yes, that's a problem, and is
one of the reasons why systemd-logind can be configured to kill all of a
user's processes at the end of their session. AIUI, the systemd people
are hoping for Linux to gain a BSD-style revoke() syscall that
systemd-logind can call on each device node it controls, which would
solve this better.)
The whole thing becomes more complex if you have multi-seat, i.e. one
PC, two video cards, two keyboards, two mice, two USB hubs. Alice and
Bob should each have access to stuff that is plugged into their own
"seat" (collection of devices in physical proximity), but not the other
one: in particular, they should each be able to use the webcam and USB
stick that are in front of them, but not the other person's. ConsoleKit
tried to solve multi-seat, with mixed results. systemd-logind also has
multi-seat as one of its goals; I'm not sure how close to a full
solution it is at this point, but I believe it's either solved or pretty
close.
Orthogonal to that, startx is basically terrible. It only works because
/usr/bin/X is setuid root, and that seems Bad™. Also, if you run it from
a virtual console, a locked X screensaver is worthless, because someone
can just switch virtual console with Ctrl+Alt+Fn, press Ctrl+C and
they're in your shell session. Also, it doesn't register sessions with
PAM, hence not with ConsoleKit or systemd-logind either, and so on;
also, it's a cruel thing to inflict on non-technical users. I strongly
recommend considering any solution that involves startx to be a "now you
have two problems" situation, and using an x-display-manager
implementation like gdm.
S
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53ab2c40.9060...@debian.org
