# DeveloperWiki:Security

This page documents progress on fixing/implementing non-CVE security-related bugs and features.

## Service Isolation

Green cells indicate a security feature is implemented, and red cells indicate the lack of a feature. If it's not possible to implement a feature without losing functionality (even if off-by-default), a reason is given instead. This also applies to features that are simply not useful, such as PrivateTmp for services without any usage of `/tmp` as these can be handled with InaccessibleDirectories.

A red cell without a link to an issue report indicates that research/testing is required in order to either mark it as not possible or report an issue.

Package | Service | User | Group | PrivateDevices | PrivateNetwork | PrivateTmp
--- | --- | --- | --- | --- | --- | ---
chrony | `chrony.service` | chrony | chrony | can use `/dev/rtc` | n/a | No
cronie | `cronie.service` | root (jobs) | root (jobs) | jobs | jobs | jobs
lighttpd | `lighttpd.service` | http | http | No | n/a | Yes
paxd | `pdnsd.service` | root (xattrs) | root (xattrs) | No | No | not used
pdnsd | `pdnsd.service` | pdnsd | pdnsd | can use `/dev/isdninfo` | n/a | not used
polipo | `polipo.service` | polipo | polipo | Yes | n/a | No
polkit | `polkit.service` | polkitd | polkitd | rules | rules | rules
privoxy | `privoxy.service` | privoxy | privoxy | Yes | n/a | No
networkmanager | `NetworkManager.service` | root | root | No | n/a | No
nginx | `nginx.service` | http | http | Yes | n/a | No
ntp | `ntpdate.service` | ntp | ntp | No | n/a | Yes
`ntpd.service` | ntp | ntp | No | n/a | Yes
tor | `tor.service` | tor | tor | No | n/a | not used
tinyproxy | `tinyproxy.service` | tinyproxy | tinyproxy | No | n/a | No
transmission-cli | `transmission.service` | transmission | transmission | No | n/a | No
wpa_supplicant | `wpa_supplicant.service` | root | root | No | No | No
znc | `znc.service` | znc | znc | No | n/a | No

### User/Group

In nearly every case, services should use an unprivileged user rather than running as root. Some cases may require the use of capabilities like CAP_NET_ADMIN or CAP_NET_BIND_SERVICE. Some exceptions are cron daemons, since they need to run scripts as root and anything needing CAP_SYS_ADMIN or a similar capability essentially equivalent to root access.

It is not appropriate to run services as `nobody`. If this user is shared among more than one service, then they are vulnerable to each other. For example, consider a caching dns server (pdnsd) running as nobody alongside ntpd running as nobody. If ntpd is compromised via a vulnerability, all the attacker should be able to do is mess with the time. However, thanks to the use of `nobody` they will be able to intercept/modify all dns requests and alter the persistent cache.

### PrivateDevices

If there is absolutely no usage of `/dev/`, then `InaccessibleDirectories` combined with `DevicePolicy=strict` is a valid alternative.

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

### PrivateNetwork

This can be used for any service without a need for network communication beyond sockets provided through socket activation.

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

### PrivateTmp

This should only be used if a service needs to make use of `/tmp`. Bash makes extensive use of `/tmp` for stuff like here documents, so any shell usage is enough to make it worthwhile.

https://fedoraproject.org/wiki/Features/ServicesPrivateTmp

### ReadOnly/ReadWrite

systemd has some basic MAC capabilities (InaccessibleDirectories, ReadWriteDirectories, ReadOnlyDirectories), but is limited to directories since it's based on bind mounts in a mount namespace. These features do not currently have the ability to recurse into submounts, causing the increase in security to be misleading. It doesn't appear that a whitelist model will work yet either, so it's far from providing true isolation at this point.

### NetworkManager / wpa_supplicant

It might be possible to drop nearly all capabilities other than CAP_NET_ADMIN. Of course, if these need CAP_SYS_ADMIN for something there's no point.

## World-readable/writeable directories

Many packages have unnecessarily world-readable directories, and some even have unnecessarily world-writeable ones. These permissions should be tightened up.

- FS#39808 - [lighttpd] /var/{cache,log}/lighttpd should not be world-readable

## Replacing setuid with capabilities

This is a scratch space tracking which packages still include setuid binaries and replacing these with capabilities where possible. Reducing setuid to CAP_SYS_ADMIN or any capabilities allowing escalation to root access is not very useful (at least without MAC/RBAC backing it up), so it will not be covered (yet?).

- FS#39686 - [inetutils] rsh, rcp and rlogin should use cap_net_bind_service, not setuid
- sudo - requires setuid

## kernel hardening

- CONFIG_SECURITY_DMESG_RESTRICT (FS#39685 - closed)
- kptr_restrict=1 (FS#34323 - closed)
- CONFIG_RANDOMIZE_BASE - does not yet work with perf and hibernate, requires dmesg_restrict=1 and kptr_restrict=1

## Compiler / linker hardening

### Stack protector

Packages missing stack protector canaries:

- python
- python2

Unimportant packages with this issue:

- xorg-xinit (xinit)

### Full RELRO

Arch passes `-z relro` to the linker in the default `LDFLAGS`, causing many internal ELF data sections to be marked read-only. However, passing `-z now` to disable lazy relocations is required to make all of these sections read-only and prevent gaining control of the process solely via modifications of the existing data. This will cause a loss in initial start-up performance, but it is negligible for most binaries.

Packages with this enabled by default via upstream build flags:

- chromium
- colord
- playpen
- openssh
- systemd
- upower
- tor

### PIE

ASLR is enabled by default, and a stronger implementation is available in linux-grsec. Data and code addresses in dynamic libraries are always randomized because these are always position independent code. However, executables are not position independent by default and cannot take advantage of ASLR. Passing `-fPIE` (or `-fPIC`) while compiling and `-pie` while linking will enable PIE, but these cannot simply be default flags because it will break libraries.

Packages with this enabled by default via upstream build flags:

- colord
- chromium
- cups
- playpen
- openssh
- sudo
- systemd
- upower
- tor

#### Example

    foo.c

    #include <stdio.h>

    static void foo() {}
    static int bar = 5;

    int main(void) {
        int baz = 5;
        printf("executable: %p, data: %p, stack: %p\n", foo, &bar, &baz);
        return 0;
    }

    $ gcc -o aslr aslr.c && ./aslr && ./aslr

    executable: 0x400506, data: 0x600988, stack: 0x7cd53a55796c
    executable: 0x400506, data: 0x600988, stack: 0x7b041f5cf6bc

    $ gcc -fPIE -pie -o aslr aslr.c && ./aslr && ./aslr

    executable: 0x9366bb52760, data: 0x9366bb53be8, stack: 0x71b21f45e7d8
    executable: 0x74e0fda6760, data: 0x74e0fda7be8, stack: 0x7f1b71444d08

## grsecurity

Two new packages will be provided, linux-grsec with the kernel and gradm with the userspace RBAC tooling. The checksec, paxtest and pax-utils utilities are already packaged, as they're useful outside of grsecurity/PaX. The paxd package fills the gap left by the lack of pacman hooks via inotify to apply PaX exceptions.

### kernel

The kernel configuration will follow the linux package's kernel configuration to the extent possible. The grsecurity patch set occasionally lags a bit behind the standard kernel so there may be minor differences due to the version.

Features breaking sensible workflows with the current set of packages in the repositories will be disabled by default. I will work towards enabling a wider set of features by default in the future.

The default sysctl.d configuration file will not touch any flags outside of the kernel.grsecurity/kernel.pax namespaces. There should be no configuration changes creating an impact on the system when booting into a kernel without grsecurity/pax support.

- i686 configuration
- x86_64 configuration

#### use upstream features where possible

Some grsecurity features have made their way upstream in one form or another. These can be preferred over the grsecurity-specific versions since backwards compatibility isn't a concern.

- kernel.grsecurity.dmesg (CONFIG_GRKERNSEC_DMESG=y) -> kernel.dmesg_restrict (CONFIG_SECURITY_DMESG_RESTRICT=y)
- kernel.grsecurity.linking_restrictions (CONFIG_GRKERNSEC_LINK=y) -> fs.protected_hardlinks, fs.protected_symlinks (set by /usr/lib/sysctl.d/50-default.conf from systemd)

#### CONFIG_GRKERNSEC_PROC=n

The protection for /proc cannot be toggled dynamically and breaks too much out-of-the-box. There's a `hidepid=2` mount option for /proc upstream with the same functionality as `CONFIG_GRKERNSEC_PROC_USER=y`. The `CONFIG_GRKERNSEC_PROC_USERGROUP=y` choice works via a trusted group, so it's a different feature, but it causes even more breakage by default and is exclusive from `CONFIG_GRKERNSEC_PROC_USER=y` anyway.

#### CONFIG_GRKERNSEC_SYSCTL_ON=n

This causes the flags to be disabled by default, as they will be enabled in a standard sysctl configuration instead. Otherwise, there is unavoidable audit spam in early boot (timechange, mount).

#### disable Yama / LSM

An equivalent to ptrace_scope is built-in to grsecurity, so there is no need for this.

#### (likely temporary) PAX_KERNEXEC / PAX_CONSTIFY_PLUGIN disabled on x86_64

These are currently disabled because I haven't been able to compile a working kernel with these enabled. These also conflict with CONFIG_XEN, so enabling these would require dropping support for running as a XEN guest.

#### PAX_MEMORY_UDEREF=n on x86_64

This is enabled on i686 (cheap, thanks to segmentation) but disabled on x86_64 for now due to the cost. Newer Intel hardware introduces features to alleviate this cost, and enabling it will make sense in the future.

#### PAX_MEMORY_SANITIZE=n

This is currently disabled due to the high cost.

### RBAC / gradm

The gradm package ships a very basic learning configuration and sample policy based on the upstream samples. It only makes simple changes to adapt these to the Arch file system layout. These is going to need more integration work to serve as a useful starting point for a user to enable without altering the configuration.

### PaX

The kernel will only be compiled with supported for the extended attribute PaX flags. The ELF flags are not always a working solution, and it's much simpler if there is only one place to look for these. With only linux-grsec installed, `kernel.pax.softmode = 1` is set to disable the userspace mitigations. Installing paxd sets `kernel.pax.softmode = 0` and it automatically applies the common set of PaX exceptions whenever a Pacman transaction occurs.

## See also

- CVE-2014

Category:

- DeveloperWiki