Russell Coker is a long-time figure in the Linux security world, having
done much of the heavy lifting involved in making SELinux work with both
the Debian and Fedora distributions. At the Debian miniconf at
linux.conf.au, Russell ran a session on what Debian should do to improve
its security. With a relatively small number of changes, Debian could be
made significantly harder to break into.
The first suggested change is not Debian-specific in any way: Russell makes
the claim that Linux needs to support more capabilities. The Linux
capability system attempts to break down the "can do anything" superuser
privileges into less powerful capabilities, with the idea that programs can
be restricted to the privileges they actually need to get their jobs done.
Unfortunately, this splitting of privileges is incomplete, in that two of
them are still too powerful. They are:
- CAP_NET_ADMIN controls the management of IP tunnels, type of
service settings, routes, interface parameters, raw packet access, and
much more. There are many unrelated powers which are granted by
CAP_NET_ADMIN; splitting them up would make the system more
secure in dealing with potentially buggy network processes.
- CAP_SYS_ADMIN is even worse, being the grab-bag capability
used whenever somebody can't find something more specific. This
capability controls access to disk quotas, the mounting of
filesystems, NVRAM access, serial port parameters, memory management
policies, and dozens of other actions. Getting CAP_SYS_ADMIN
is not far removed from simply having superuser powers.
Russell talked about the benefits of splitting up these capabilities, but
didn't get much into the practical difficulties. Those include the fact
that the 32-bit capability mask is just about full already, the need to
educate developers and administrators about the new capabilities, and the
task of changing the current capability tests and dealing with the things
that break. It's an obviously good idea, but carrying it through will
require some work.
Next on Russell's list is polyinstantiated directories. In words of fewer
syllables, this means directories where each user gets his or her own,
private copy. When applied to shared directories like /tmp,
polyinstantiated directories can help defend the system against symbolic
link and temporary file attacks. The necessary support is already there -
the kernel has filesystem namespaces, shared subtrees, and the PAM
modules to control these features. It's just a matter of hooking it all
together in a way that works.
The ExecShield patch set is the next suggestion. In particular,
Russell would like to see protection against executable stack and
writable memory-mapped segments. As he pointed out, Fedora and Red Hat
Enterprise Linux have shipped this feature for some time with little in the
way of ill effects. It's mostly a matter of getting some of the remaining
patches into the kernel mainline - or maintaining them separately in the
The TIOCSTI ioctl() command allows a process to stuff
characters into a terminal device, from which they will later be read. If
a hostile user can get an administrator to switch over to his account (with
su, say), he can use this ioctl() to take over the
administrator's shell. Ways of avoiding this attack include not using
su in a number of situations - for example, by using ssh
to log in as another user. The setsid() system call can also be
used to create a barrier to defend against character-stuffing attacks.
Next is better support for Xen, especially at install time. Russell would
like to be able to install a Debian server system where the only thing
found in the host domain is an SSH server and the tools needed to get the
guest domain running. All of the real server tasks would run in the
guest. Then, if that guest is compromised, the core server's integrity
remains, and it can be used to examine the guest closely. Among other
things, rootkits running in the guest will have a much harder time hiding
from an administrator running on the host.
Finally, Russell suggested that the Debian release following etch should
install and run SELinux by default - just like Fedora does. Just running
SELinux improves security, but things get better when the developers use it
as well. SELinux can block attacks, but, when used by developers, it can
reveal security-related bugs before anybody gets a chance to exploit them.
In essence, SELinux is a language which is used to describe the expected
behavior of an application; when the application deviates from the
expectations, SELinux sounds the alarm and allows the situation to be
to post comments)