Hello list, I am a security engineer with the SUSE Linux security team. We have been approached with worries about the "brltty" service user being a member of the "root" group in the packaging of brltty on openSUSE Tumbleweed.
Taking a closer look it turns out that brltty uses the following
privileges on Linux, as is also documented in the brltty repository in
Documents/README.Linux.
Group memberships:
- audio: For playing sound via the ALSA framework.
- brlapi: For reading BrlAPI's key file.
- dialout: For serial I/O via /dev/ttyS*, /dev/ttyACM*, /dev/ttyUSB*
- input: For monitoring keyboard input via the devices in /dev/input/
- pulse-access: For playing sound via the Pulse Audio daemon.
- root:
- for USB I/O via USBFS (using the devices in /dev/bus/usb/).
- for creating virtual devices via the uinput device.
- tty:
- for reading screen content via the /dev/vcs devices.
- for virtual console monitoring and control via the /dev/tty<n> devices.
Additionally the brltty daemon also keeps the following Linux capabilities:
- cap_mknod: For creating needed but missing device files.
- cap_sys_admin: For injecting input characters typed on a braille device.
- cap_sys_tty_config: For playing alert tunes via the speaker.
So in summary, when looking at a running brltty daemon, it seem it is
using privilege separation running as a dedicated brltty service user.
But in fact the daemon practically has full root privileges, especially
via the root group membership and the CAP_MKNOD and CAP_SYS_ADMIN
capabilities.
We want to raise awareness that an average administrator might wrongly
believe that there is a strong privilege separation in place for brltty
while it actually is not. In this light it might even be more honest to
run the daemon as root right away to avoid any false promises. Some
Linux distributions like Debian actually seem to do this (or
they simply never bothered to setup the privilege separation in the
first place).
On a technical level we would find it useful when privileges are only
configured / retained if there is an actual need for it. Depending on
the actual use case and configuration only parts of these privileges
will ever be needed by the brltty daemon.
Some of these privileges like CAP_MKNOD for "creating needed but missing
device files" also seem deprecated these days on Linux, where device
nodes are exclusively managed by udev.
Furthermore it is common practice to use raised privileges only during
startup to e.g. open a specific device file, then drop the privileges
permanently for the rest of the lifetime of the daemon. Some of the
access problems could also be solved using udev rules that grant special
access to brltty for matching devices.
Maybe this is an area where brltty on Linux can be improved in future
releases.
Regards
Matthias
--
Matthias Gerstner <matthias.gerst...@suse.de>
Security Engineer
https://www.suse.com/security
GPG Key ID: 0x14C405C971923553
SUSE Software Solutions Germany GmbH
HRB 36809, AG Nürnberg
Geschäftsführer: Ivo Totev, Andrew McDonald, Werner Knoblich
signature.asc
Description: PGP signature
_______________________________________________ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: BRLTTY@brltty.app For general information, go to: http://brltty.app/mailman/listinfo/brltty
