Kernel Summit: Security [LWN.net]

This article is part of LWN's 2004 Kernel Summit coverage.

James Morris led a session on security. He noted that a great many security features have found their way into 2.6; these include the Linux security module mechanism, the crypto API, the dm-crypt target, IPSec, SELinux, NX bit support, the audit framework, and more. Still, there are things yet to be done. These include:

In-kernel keyring management. So far, the kernel has had little need to manage cryptographic keys in its own right, but that is likely to change. A simple patch has been posted, more work remains to do.
An audit framework. The lightweight framework recently merged into 2.6 is a step in the right direction, but there is apparently more to do. It would be best if all distributions used the same framework; it would make certification easier.
SELinux has some performance issues, especially in the networking area. The problems seem reasonably well understood, and ideas for solutions are being kicked around.
SELinux also apparently needs multi-level security for groups dealing in classified data and similar materials. One might be forgiven for thinking that SELinux is already sufficiently complex, but it would seem that more complexity is required.
"Labeled networking" is another wishlist item; it would allow packets to be marked on entry to a network and handled according to those labels.
The integration of resource management code, presumably the class-based resource management mechanism.
Virtualization work, allowing the complete isolation of processes running on virtual machines.
Extension of the crypto API to support hardware encryption devices.
Signed modules and binaries. The signed module patch is in circulation, and is part of the Fedora test release; signed binaries are further away. Linus asked if any developers were worried about the implications of this work, but nobody raised any complaints.
Support for "trusted computing" platforms.
"Better capabilities"; what "better" means was not really specified. It was noted that nobody is using the existing capability mechanism, which, until recently, did not even work very well.

>> Next: Class-based Kernel Resource Management.

(Log in to post comments)

Complexity! Yuck!

Posted Jul 22, 2004 2:44 UTC (Thu) by AnswerGuy (guest, #1256) [Link]

SELinux is impossible for mortals to administer!

I would vastly prefer to see the systrace patches applied and defer
most of that complexity to a user space reference monitor.

Of course systrace and SELinux are not mutually exclusive so the small,
relatively simple, systrace patch could be applied and offered as an
option in the mainstream along with SELinux.

As for the auditing patch --- how many of the hooks for auditing can
also be used for dprobes? One would think that many of them would
coincide or overlap.

JimD

Labeled Networking: Reserved vs. Implemented

Posted Jul 22, 2004 18:31 UTC (Thu) by AnswerGuy (guest, #1256) [Link]

I think there are fields in the IP header which are reserved for this, but very few TCP/IP stacks support any use of that field.

Implementing support for this in Linux would seem to be a simple matter of coding up the appropriate netfilter modules and adding support to iptables, the iproute2 package or other utilities to set kernel policies regarding these labels.

I'm curious what the intended application would be.

JimD