FS#64874 - [bird] run bird as a normal user

Attached to Project: Arch Linux
Opened by Tim (bastelfreak) - Tuesday, 17 December 2019, 14:52 GMT
Last edited by Sébastien Luttringer (seblu) - Monday, 26 April 2021, 21:27 GMT
Task Type Feature Request
Category Security
Status Closed
Assigned To Sébastien Luttringer (seblu)
Levente Polyak (anthraxx)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description: Our bird service file starts the daemon as root. I expected that it runs as a normal user (not sure if this classifies as a bug / security incident).


Additional info:
* package version(s)
2.0.7-1
* config and/or log files etc.

The current service file:
[Unit]
Description=BIRD routing daemon
After=network.target

[Service]
Type=forking
ExecStart=/usr/bin/bird
ExecReload=/usr/bin/birdc configure
ExecStop=/usr/bin/birdc down

[Install]
WantedBy=multi-user.target

I did some tests and think the following unit file makes more sense (and it works for me):
[Unit]
Description=BIRD Internet Routing Daemon
Wants=network-online.target
After=network-online.target

[Service]
Type=simple
ExecStart=/usr/bin/bird -f -u bird -g bird
ExecReload=/usr/bin/birdc configure
ExecStop=/usr/bin/birdc down
Restart=on-failure

[Install]
WantedBy=multi-user.target

(the package needs to be updated to also create a bird user)
Closed by  Sébastien Luttringer (seblu)
Monday, 26 April 2021, 21:27 GMT
Reason for closing:  Implemented
Additional comments about closing:  2.0.8-3
Comment by Levente Polyak (anthraxx) - Tuesday, 17 December 2019, 16:58 GMT
I dont think the application needs a dedicated bird user that owns files on the filesystem, hence it may classify for a simple usage of DynamicUser
while on it, it would make sense to define hardening settings for the unit as well
Comment by Tim (bastelfreak) - Wednesday, 18 December 2019, 19:14 GMT
the application exposes a unix socket which is owned by the user, and only certain people/accounts, not everbody but also not nobody else, need to access it. Does that qualify for a dedicated user? In my environment the service runs as user bird, the socket is owned by bird:bird and my monitoring software runs as another user which got added to the bird group.
Comment by Sébastien Luttringer (seblu) - Friday, 21 February 2020, 21:44 GMT
Bird may push routes into the kernel tables, so it requires special capabilities if we want to run it as user.
Comment by Sébastien Luttringer (seblu) - Tuesday, 19 May 2020, 23:17 GMT
Instead of closing it, I've updated the bug report in a feature request to improve security around bird.

I guess we could use a dynamic user and harden the unit and grant it CAP_NET_ADMIN for network stuff.
Comment by Sébastien Luttringer (seblu) - Tuesday, 13 April 2021, 13:00 GMT
A new version 2.0.8-2 of package will enter [testing] soon. The service will now run with a strictly positive uid, limited capabilities and filesystem access. Bird control socket has been moved into /run/bird.

I didn't assigned a global static uid/gid pair to bird, as it's not required until you need to set permissions on the control socket. When this is required (like by Tim usage), the root user could create a static local group named bird to add allowed local users into the group to give them socket rw access.

As a side note, build tools has been fixed upstream so we can now use them like with other packages.

Let me know if something is broken or worse.

Loading...