This document outlines the kernel security improvements that have been made in the 2.4 kernel. A number of significant improvements including cryptography and access control make 2.4 a serious contender for secure corporate environments as well as private virtual networking.
One of the most obvious and significant improvements in the 2.4 kernel is
the packet
filtering capabilities. However, there are a number of other
improvements that make Linux one of the most secure operating systems
available.
Capabilities: Removing Dependance on "root"
As you know, the "root" user normally has complete control over all functions
of a Linux box. Binding to a privileged port, loading kernel modules, and
managing filesystems are examples of things that typically can only be done
by root. If a regular user needed to run the "ping" command, for example,
it was necessary to make it run with the privileges of the root user. The
ping binary needs root privileges in order to open a raw socket (an operation
managed by the kernel) to create the necessary ICMP packet for the echo
request.
Another classic example is the time server, xntpd. In order to bind to
the privileged ntp port, the daemon requires root privileges. If we could
somehow simply supply the ntp daemon with root privileges for the time
it takes to manipulate the system clock as the daemon starts, then lower
its privileges to that of a normal user before processing actually starts,
we can significantly reduce the potential for a programming error from
compromising the whole system.
Once these privileges are relinquished, it's effectively gone until the next
reboot. Even another root process cannot regain those privileges.
This is where capabilities become a critical next step in the evolution
of system and kernel security. Capabilities support extends the UNIX
security model and allows Linux to provide more fine-grained access to
privileged system commands. It is a set of "rules" that can be assigned to
processes, users, and files that even the root user must follow.
Linux 2.2 introduced basic support, but a modification by Chris Evans to
the 2.4 kernel turned capabilities into a system that is largely useable
and can be programmed into many of the common services, such as the
ntp daemon. Chris' change involved a modification to the
prctl() system call that permits a program implementing
capabilities to retain its existing level of capabilities while switching from
running as root to a non-root user.
Originally a POSIX.1e specification, now
withdrawn but still a useful guide, Linux 2.4 implements nine of the
capabilities from the original draft, and an additional twenty-one that
are specific to Linux.
Some of these capabilities include the ability to change file ownership,
kill processes, control kernel module management, reboot or shutdown the
machine, manipulate the system clock, and more. One can immediately see
how powerful this is -- processes that are normally set-user-id root
such as /bin/ping or simply must be run as root can now run with just
the privileges they need and no more, diminishing the likelihood of a
security problem resulting in a system compromise.
Capabilities can also be controlled on a system-wide level using a "bounding
set." The ability to load or unload modules might be one such capability.
The CAP_SYS_MODULE
might be disabled once the system has booted and entered the normal
multi-user level to prohibit the loading or unloading of kernel modules
essentially until the next reboot. Using the lcap command, one might
disable the ability to load kernel modules using the following:
[root@magneto /root]# lcap CAP_SYS_MODULE
This would typically be done at the first point at which all the necessary
modules have been loaded. This is an effective countermeasure against
a malicious intruder attempting to install a backdoor kernel module. The
CAP_SYS_RAW_IO capability would also disabled to prevent hacking kernel
memory directly using /dev/kmem.
A program such as xntpd might go through the following process to
relinquish the rights that are not necessary for normal operation:
- Start with full root privileges as it normally does
- Bind to the privileged ntp port
- Drop all capabilities other than CAP_SYS_TIME
- Drop root privileges (preventing it from even writing to root-owned files)
- Continue normal operation as a regular administrative account
Future changes yet to be completely implemented include the modification
to commands similar to chattr(1) to modify and tag files that will one day
totally remove the concept of a "root" user. The goal is to provide the
ability for a command-line tool to add or remove privileges in much the same
way we current add or remove permissions using chmod(1).
Currently, programs need to be modified to take advantage of capabilities.
With filesystem capabilities, this sometimes won't be necessary. It might
go something like this:
[root@magneto /root]# chattr +CAP_BIND xntpd
This would enable the xntpd process to bind to a socket without requiring
root privileges prior to being run. Quite powerful. At the same time, it's
also contains a certain potential danger due to making an unprivileged binary
slightly privileged.
Open Source Cryptography:
Encryption is the key to the next generation of Internet communications.
No longer is it possible to use the protocols that were commonplace in
times before electronic commerce, companies relying on their Internet
presence for interacting with customers, and even basing their corporate
image on it.
Changes in the crypto export regulations in October of 2000 now make it
possible to not only distribute open source cryptography from a web site
freely, but also object code derived from open source software. The
origin location of the source code must send a message to the Bureau of
Export Administration
indicating their intent.
The kernel.org web site now has a cryptography
repository, and contains crypto extensions to the new 2.4 kernel that
provide the ability to encrypt filesystems, create virtual private
networks, and more.
I had an opportunity to speak with Alexander Kjeldaas, the lead developer
for the kernel crypto work, and asked him about the state of support of
crypto in the 2.4 kernel.
"Lots of ciphers are supported -- the ones most currently used such as
Blowfish,
IDEA,
Serpent,
AES,
3DES, DES and others. Some digest algorithms are also supported - MD5 and
SHA1. No hardware acceleration is supported yet. The API is mostly
synchronous the way most crypto APIs are designed, but when we start
getting hardware acceleration this might change and we might get an
asynchronous interface -- developing this interface will probably be done
with an eye on the IPSec needs. Only symmetric ciphers are supported --
no asymmetric stuff (RSA, etc.) is supported or planned."
He also gave me some insight into what changes we can look forward to with
regard to security and Linux in the future.
- Encrypted swap based on /dev/loop will hopefully be work during 2.4.
Swapping is a bit tricky since you can't allocate memory during
write-out. In time, we might want to have a notion of an encrypted
device that is controlled by a table of keys instead of a single key.
One key would control a segment of the device and the individual keys
could be exchangeable. This is especially useful for implementing
encrypted swap. By having a table of keys, the swap code can "erase"
a section of the swap-device as soon as this section becomes unused by
changing a key in the key-table. This improves the security of
encrypted swap for long-running servers.
- Getting the patch integrated (with the kernel and distributions).
Update: Ask for, and you shall receive. Jens Axboe, author of the crypto loop code,
dropped me a note after this article was published stating, "crypto swap should work
with the loop I rewrote and is in the 2.4.2-ac series. It will be in the stock
kernel soonish."
Other crypto-related stuff to look forward to:
- IPSec being integrated in distributions
- I am a big fan of type enforcement, so I really look forward to seeing
something like the NSA-sponsored work getting integrated. I hope the
Linux community sees the need for these kinds of security
frameworks.
- I also really like StegFS.
Kernel Devices and Configuration Options:
The 2.4 kernel includes a few block and character devices available on Linux
that will also help you with security. Although not necessarily new in
the new 2.4 kernel, they are relatively unknown but extremely powerful.
These devices, /dev/random and
/dev/urandom, are managed by the kernel and provide random
data at any time for any number of applications. This might include generating
random passwords, seeding TCP sequence numbers, and even cryptographic
functions.
Both /dev/random and /dev/urandom
should be secure enough to use in generating PGP keys, SSH challenges, and
other applications where secure random numbers are requisite. Attackers should
be unable to predict the next number given any initial sequence of numbers
from these sources. There has been a lot of effort put in to ensuring that the
numbers you get from these sources are random in every sense of the word
random.
The only difference is that /dev/random runs out of random
bytes and it makes you wait for more to be accumulated. Note that on some
systems, it can block for a long time waiting for new user-generated entry to
be entered into the system. So you have to use care before using
/dev/random.
/dev/random is high quality entropy, generated from
measuring the system interrupt times and other events which are
non-deterministic. It blocks until enough bits of random data are available.
/dev/urandom is similar, but when the store of entropy is
running low, it'll return a cryptographically strong hash of what there is.
This isn't as secure, but it's enough for most applications.
You might read from the devices using something like:
[dave@magneto /home/dave]# head -c 6 /dev/urandom | mmencode
This will print (approximately) six random characters on the console,
suitable for password generation. You can find mmencode(1)
(perhaps also known as mimencode on some systems) in the metamail mail
package.
See /usr/src/linux/drivers/char/random.c for
a description of the algorithm.
Final Notes:
In this article we've covered the new features available in the 2.4 kernel.
In the months to come, we expect distribution vendors to start including
cryptography directly with their releases, efforts in auditing, improved
access control mechanisms, and new software to be developed around these
projects to increase.
Currently, there are at least three different access control projects that
utilize the foundation set forth by the 2.4 kernel, many cryptography
projects to provide IPSec compliance and interoperability with commercial
products, and much more.
It's an exciting period in computer security.
Acknowledgements:
Special thanks to Chris Evans for his efforts, without which I couldn't have
created this document. Thanks to H. Peter Anvin for his help with the crypto
section and comments about kernel.org. Thanks to Alexander Kjeldaas for
his comments on the state of kernel crypto, and thoughts on the future.
About the Author:
Dave Wreski is the technical lead for linuxsecurity.com, co-author of the
Security HOWTO and other Linux security articles and documentation. He also
works with Guardian
Digital, the open source security company and sponsors of
linuxsecurity.com.
Disclaimer:
You should be aware that I'm not a legal expert, and the information
contained within this document (specifically with regards to the crypto
section) should not be interpreted as such. While every effort has been
made to provide the most accurate information available, it may be different
in your particular situation, and you should be sure to contact a real
legal professional before making any decision on this matter.
Resources:
The Bureau of Export Administration Website
http://www.bxa.doc.gov/Encryption/Default.htm
Linux-Privs Project
http://www.linuxsecurity.com/resource_files/.../linux-privs.html
Linux Capabilities FAQ 0.2
ftp://ftp.guardian.no/pub/free/linux/capabilities/capfaq.txt
LCAP - Linux Kernel Capability Bounding Set Editor
http://pweb.netcom.com/~spoon/lcap/
Only registered users can write comments.
Please login or register. Powered by AkoComment! |
