Linux Security Levels
... isn't hiding your root password security through obscurity ?
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
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? ;-)
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
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.
- 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
- 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
- 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.
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).