F21 System Wide Change: PrivateDevices=yes and PrivateNetwork=yes For Long-Running Services

Jaroslav Reznik jreznik at redhat.com
Wed Mar 26 14:06:36 UTC 2014


= 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. 

_______________________________________________
devel-announce mailing list
devel-announce at lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce


More information about the devel mailing list