I'd like to ask you to update the guideline to recommend enabling systemd's PrivateDevices= and PrivateNetwork= settings for all long-running services.

This is in-line with the accepted F21 feature posted here (which includes a rationale why):

https://fedoraproject.org/wiki/Changes/PrivateDevicesAndPrivateNetwork

Proposed text would be:

"If you package a long-running system service, please consider enabling systemd's PrivateDevices= and PrivateNetwork= settings for it, in order to improve security and minimize the attack surface.

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:

• Services that actually require physical device access
• 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.
• 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:

• Services that actually require network access (with the exception of daemons only needing socket activation)
• Services which may be used to execute arbitrary user or administrator supplied programs. (see above)
• 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.
• 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).
• 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.

For further details see the systemd.exec(5) man page."

(Oh, and please only recommend this for Fedora 21 and newer, before that the two options didn't work the way described above, or didn't exist.)