Linux Security Levels

... isn't hiding your root password security through obscurity ?

About

Security levels are a facility which allows to scale global control over the system to several levels. You can limit various actions or permissions to be valid only to certain level, thus allowing maintainence operations only under special controlled conditions and disallow actions not needed during normal operation. This can very significantly enhance the security of the server even if it is already compromised and based on the actual restrictions being employed it could even prevent any damage being actually done by the intruder.

This idea can resemble *BSD security levels, but it is much more powerful, flexible and customizable for actual admin's needs (see below about details). It is also designed to be as generic as possible and it aims not to introduce a complete complex security policy on its own but rather provide a simple and easily configurable and useable framework to which verios more specific security policies can also tie some of their restrictions. I even hope to eventually get this to the stock kernel at some distant misty point in future; I will probably have to fuddle Linus, which alcohol does he prefer? ;-)

Description

There are 8 security levels, from 0 (the least secure) to 7 (the most secure). At any time, you can (if you have that permission/capability) raise the security level (reducing overall permissions), but you can lower the security level only under very special conditions, considered as "really secure" (that depends on configuration, by default you just can't; you could connect some external device to confirm it, or confirm it cryptographically, or whatever...; you can adjust possibility of usage of various methods depending on the current securelevel as well). The current security level number is available to the userland so that various userland utilities can act accordingly as well. You can also restrict any bit in any file's permission mask to be valid and changeable only to certain security level, thus you can block various operations upon your files from a system's security level you choose (those limitations cannot be overriden even by superuser).

This is the recommended structure of the security levels scale:

Security Level 0

Default mode, normal operation. Everything is allowed as in the default unsecured Linux system. Fear upon hags.

Security Level 1

Almost normal operation but the most dangerous actions. This means direct write access to raw block devices of mounted filesystems and access to devices representing raw memory (/dev/*mem, /proc/kcore) (unfortunately there has to be exception that /dev/mem can be mmap()ed since X wants to do that). You also cannot lower the security level anymore. This is intended as the normal mode of operation for the usual desktop linux systems.

Security Level 2

This completely locks userspace into itself, preventing to modify or sidestep the kernel in any way. Direct access to hardware is prohibited even for applications with CAP_SYS_RAWIO (usually all tasks running as root) and no modules can be inserted/removed from the kernel. You cannot write to any raw block devices anymore. This is intended as the normal mode of operation for most of the server linux systems.

Security Level 3

Try to make sure that the configuration cannot be altered unauthorizedly. Makes it impossible to change immutable and append file attributes. Devices cannot be (un)mounted, swap devices cannot be reconfigured and mknod() call is disallowed. You are banned to set the time backwards or close to overflow (you can still make the time flow slower, though). Hostname and domainname cannot be changed, nor can be the printk logging level.

Security Level 4

This employs even stricter anti-reconfiguration policy, mainly network-wise --- by now it should be already impossible to break the configuration in any way. System prevents you to touch the network interfaces configuration and routing table and iptables rules. Quotas cannot be adjusted, nor can be process accounting. The chroot() call is disabled.

Security Level 5

Attempt to protect running processes from any possible unauthorized distractions. Prohibits even tasks with CAP_KILL (root tasks) to kill processes of other users and disallows ptrace()ing of processes; processes cannot be reniced and files cannot be leased. Aside of that, root cannot anymore turn the promiscuous mode on/off for any interface nor create raw sockets. No process can bind on port < 1024 and setuid() call is banned (plus setuid bit in file permissions is ignored, obviously).

Security Level 6

By now all the special privileges of the root account are disabled. No resource exceptions are applied to root, she is treated as normal user and cannot override the limits. And she cannot adjust time in any way, she cannot reconfigure terminals, any ioctl()s are prohibited (?), chown() is disallowed. You cannot even reboot the machine now.

Security Level 7

This is left for other special security modules as the placeholder for any further possible restrictions, the stock kernel doesn't implement any of the limitations recommended for this level: non-root users can't see other processes and can't even list the system configuration (almost anything in /proc and /sys is non-accessible, sysctl() is unusable), only .text segment should be executable. Some possible special accounting could be employed here. Daemons should ignore any signals or administrative commands and only respond to ordinal user requests.

(note that this is just the default configuration, you can reconfigure the action permissions map however you wish)

...TODO : provide the actual privileged actions list and describe the userspace interface...

Status

Currently, I develop first version of the patch (against 2.5's LSM), I will make it available as soon as it will do anything useful.

The first primitive version of the patch (0.1, against 2.5.64) is here.

TODO list

• Only small subset of the actions is implemented now, mainly those which can be easily bound to capabilities.
• Documentation, now its missing except blurb, intuition, sources and /sys/security/levels/actions/*/desc.
• init(8) needs to be aware of CAP_SYS_BOOT. I mean it shouldn't change to evil runlevels if reboot action's level threshold is <= security level. But the runlevels are completely user-configurable, so we should probably rather place the checks to the support scripts. It's up to the local configuration then, but we should provide some examples and thoroughly document this. Now, we _do_ check CAP_SYS_BOOT, but only in kernel in reboot() handler and if it will return -EPERM it won't help us anyway if we are calling it from init since the system will be freezed anyway.
• There are no real secure authentication methods available yet and you cannot restrict them by security level yet; the framework is not there and it is only an ad hoc code now ;-).
• Introduce CAP_LINUX_SECLEVEL which permits task to raise the security level.
• Right now, some of the actions are tied to capabilities, thus not allowing enough fine-grained configuration (mainly CAP_NET_ADMIN and CAP_SYS_ADMIN) --- for CAP_NET_ADMIN it means now that some of the actions are took out too early, for CAP_SYS_ADMIN it means now that some of the actions are took out too late (it mixes some hardware and device configuration and swap, filesystems and hostname configuration *shudder*). I can see a lot of new LSM hooks dropped around so that this could be workarounded :-(.
• Per-process individual securelevels are needed: it should be possible to "lock" certain set of processes (either by pid or runtime binary path) plus their children in certain securelevel >= the current securelevel .oO(/sys/security/levels/stickytasks/ ;). By default, init would be then stick in security level 0, so that it could gradually reduce security levels during shutdown (which it would make sure is authorized, thus happenning in security level 5 or lower).
• Should SysRq functionality be adjustable? If yes, when you get to level 6 you don't already have any possibility to even reboot the system. Scary.

Contact

This patch is based on some ideas of Pavel Troller. The ideas are being finetuned and coded by Petr Baudis with little comments and help of few people from #linux.cz @ IRCNet and #kernelnewbies @ OFTC (or OTFC or whatever it is named like).