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