Re: dbus: Removing pam_console, pam_foreground, /var/run/console support?

On Mon, 03 Jul 2017 at 12:54:59 +0200, Lennart Poettering wrote:
> I'd even go further
> even, and drop the concept altogether and simply say that all
> non-system users as well as root itself are considered at the
> "console". I doubt the current users of this concept would be severely
> weakened if they'd stop distuingishing between local and remote users
> and would instead just grant access to all users that aren't system
> users (because ultimately at_console users are just a subset of the
> non-system users).

I don't think this is wise: it's granting accesses that were not
previously granted. at_console is not great, but it's what we have;
if we are going to change it at all, we should make it more strict
(for example the trivial implementation of not considering anyone to be
at the console), not more lenient.

I believe the intention of at_console is that it's like udev/systemd
uaccess or polkit allow_active/allow_inactive: it gives permissions
to users who are physically sitting at the computer, so that they can
use features that go with physical presence, like audio, short-ranged
networking (e.g. Bluetooth) and power management (justified by the
fact that local users are typically in a position to pull the power
cable and/or battery, so there is no point in preventing them from doing
a controlled shutdown).

If we grant those permissions to all user accounts (uids representing
actual humans, such as uid 1000-59999 on Debian[1]) then we open up
the ability for remote user Alice to interfere with local user Bob's
Bluetooth audio device while logged in via ssh, which I suspect could be
a significant privacy issue (although I don't know the specifics of how
BlueZ works). This is similar to the way we prefer to use udev/systemd
uaccess to put ACLs on audio devices, because if we instead put both
Alice and Bob in group audio like typical 90s/00s Linux distributions
did, they can use a ssh connection or cron job to record each other
while close to a shared computer, which would be a huge privacy violation.

If we want to grant permissions to user accounts but not system users,
that should be <policy context="user_accounts"> or something. But to
do that, we'd need to have ./configure options or system.d configuration
to teach dbus-daemon which uid ranges are user accounts, which is not
really something I want to be getting into if I can avoid it.

    S

[1] https://www.debian.org/doc/debian-policy/ch-opersys.html#s9.2.2
_______________________________________________
dbus mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dbus