Following up on this post, we want to provide some details on two rather new (well, compared to its lifespan) Linux kernel parameters — and emphasize the need to enable those:
- fs.protected_hardlinks
- fs.protected_symlinks
For BSD, similar parameters for hardlinks exist: security.bsd.hardlink_check_uid/security.bsd.hardlink_check_gid.
Those parameters control whether users are allowed to create links pointing to files which are not owned by them. If fs.protected_hardlinks/symlinks is set to 1, users can only create links to files which they own. Attackers have used this possibility for a long time, and here are some sample attack scenarios:
- Link a non-readable file to a place which is potentially covered by privilege changes:
> ln /etc/shadow ~/shadow
# wait for an administrator/cronjob to do something like that:
> chown -R myuser:myuser ~ - Bypass sudo restrictions: Even though we all know that it is a bad idea to use sudo (also in general 😉 ) and assume you can restrict users to certain actions, some organizations/sysadmins still do it. And configurations like this can be bypassed using hardlinks:
> cat /etc/sudoers
myuser ALL=NOPASSWD:/usr/bin/vim /home/myuser/*
> ln /etc/shadow ~/shadow
> vim ~/shadow - Perform all kinds of race condition-like redirecting attacks, e.g. redirecting cronjobs which write their output to a file in /tmp (maybe created based on the current time). Linking the target files (or a number of target file, to cover a range of time) to files like /etc/profile to inject code. For a long, incomplete list of such vulnerabilities refer here.
Deploying those parameters should not result in high operational effort and will provide some more protection against local privilege escalation (we actually used attacks similar to the ones described to compromise thoroughly hardened and patched Linux boxes a number of times). You should consider enabling them in your environment — we will update our SLES hardening guide soon (as SLES only supports the parameters from SLES12 on).
Best,
Matthias