= Proposed System Wide Change: PrivateDevices=yes and PrivateNetwork=yes For Long-Running Services = https://fedoraproject.org/wiki/Changes/PrivateDevicesAndPrivateNetwork

Change owner(s): Lennart Poettering <lennart at poettering dot net>, Dan Walsh, Kay Sievers

Let's make Fedora more secure by default! Recent systemd versions provide two per-service switches PrivateDevices=yes/no and PrivateNetwork=yes/no which enable services to run without access to any physical devices in /dev, or without access to kind of network sockets. So far this has seen little use in Fedora, and with this Fedora Change we'd like to change this, and enable these for all long-running services that do not require device/network access.

== Detailed Description == When PrivateDevices=yes is set in the [Service] section of a systemd service unit file, the processes run for the service will run in a private file system namespace where /dev is replaced by a minimal version that only includes the device nodes /dev/null, /dev/zero, /dev/full, /dev/urandom, /dev/random, /dev/tty as well as the submounts /dev/shm, /dev/pts, /dev/mqueue, /dev/hugepages, and the /dev/stdout, /dev/stderr, /dev/stdin symlinks. No device nodes for physical devices will be included however. Furthermore, the CAP_MKNOD capability is removed. Finally, the "devices" cgroup controller is used to ensure that no access to device nodes except the listed ones is possible. This is an efficient way to take away physical device access for services, thus minimizing the attack surface.

When PrivateNetwork=yes is set in the [Service] section of a systemd service unit file, the processes run for the service will run in a private network namespace whith a private loopback network interface, and no other network devices. Network communication between host and service can not be initiated. This is an efficient way to take away network access for services, thus minimizing the attack surface.

By default both switches default to "no".

Note that PrivateDevices=yes should not be used for:

1. Services that actually require physical device access 2. Services which may be used to execute arbitrary user or administrator supplied programs (such as cron, ...). We shouldn't limit what people can do with these services. 3. This option creates a new file system namespace where mount/umount propagation is turned off back into the host. This means that mounts made by the service will stay private to the service. Thus this option should not be used by services which shall be able to establish mounts in the host.

Note that PrivateNetwork=yes should not be used for:

1. Services that actually require network access (with the exception of daemons only needing socket activation) 2. Services which may be used to execute arbitrary user or administrator supplied programs. (see above) 3. Services which might need to resolve non-system user and group names. Since on some setups resolving non-system users might require network access to an LDAP or NIS server, enabling this option on might break resolving of these user names. Note however that system users/groups are always resolvable even without network access. Hence it is safe to enable this option for daemons which just need to resolve their own system user or group name. 4. This also disconnects the AF_UNIX abstract namespace from the host (In case you wonder what this refers to: sockets listed in /proc/net/unix that start with an @ are in the abstract namespace, those which start in / are in the file system namespace). This means that services which listen or connect to AF_UNIX sockets in the abstract namespaces might break. AF_UNIX sockets in the file system continue to work correctly even with PrivateNetwork=yes. We strongly recommend anyway to stop using abstract namespace AF_UNIX sockets, as they bring very little benefit these days. If your package uses them please consider moving them into the file system into a subdirectory in /run (system services) or $XDG_RUNTIME_DIR (user services). 5. This also disconnects the AF_NETLINK and AF_AUDIT socket families from the host. For services requiring auditing, that need to subscribe to network configuration changes, or want to subscribe to hardware devices coming and going (udev) PrivateNetwork=yes cannot be used hence.

The focus for this change is to turn one or both switches on, primarily on long-running services, and not on services that quickly run at boot and do not stay running continuously afterwards.

== Scope == * Proposal owners: We'll file a number of bugs to more important packages where PrivateDevices=yes and/or PrivateNetwork=yes might be applicable.

We'll also update systemd itself to make use of these options for all its own services, where this is applicable. (DONE)

* Other developers: Fedora developers should check whether their long-running services might be candidates for PrivateDevices=yes and/or PrivateNetwork=yes, and if so set these settings for their services.

* Release engineering: Nothing required.

* Policies and guidelines: It might be nice to update the packaging policies to also recommend making use of these settings.