LCA: How to improve Debian security [LWN.net]

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 Debian kernel.

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 investigated.

Index entries for this article
Security	Distribution security
Security	Linux kernel/Linux/POSIX capabilities
Conference	linux.conf.au/2007

to post comments

LCA: How to improve Debian security

Posted Jan 18, 2007 11:19 UTC (Thu) by ekj (guest, #1524) [Link] (1 responses)

In theory stuff ougth to be more secure with more fine-grained security.

In reality, however, complexity is the enemy of security. It is much harder to configure a system with a bazillion roles so that every user, every group and every program has precisely the access that they need than it is to do the same correctly with a more coarse system.

I'm not convinced it's an overall win to introduce something which is theorethically somewhat more secure while being stupendously more complex.

LCA: How to improve Debian security

Posted Jan 18, 2007 16:21 UTC (Thu) by nix (subscriber, #2304) [Link]

A good few Debian developers of my acquaintance agree with you...

VMS had an interesting approach to capabilities

Posted Jan 18, 2007 18:23 UTC (Thu) by JoeBuck (subscriber, #2330) [Link]

I used to work with VMS way back in ancient times. The VMS documentation classified privileges according to the potential damage someone with the privilege could do. To quote a bit from this link:

Privileges fall into the following seven categories according to the damage that the user possessing them could cause the system:

None: No privileges
Normal: Minimum privileges to use the system effectively
Group: Potential to interfere with members of the same group
Devour: Potential to consume noncritical systemwide resources
System: Potential to interfere with normal system operation
Objects: Potential to compromise the security of protected objects (files, devices, logical name tables, global sections, and so on)
All: Potential to control the system

A process with no privileges can't use the network or communicate with other processes. As I recall, temporary mailboxes play a role in I/O, so I think a process with no privileges can't even open or close files or streams, but can only read and write from existing ones.

The large numbers of distinct privileges in the "All" category seems to me to reflect design mistakes: given any of about 10 privileges a bad guy can trivially obtain all the others, so the separation doesn't achieve much.

non C based environments can have problems

Posted Jan 19, 2007 12:49 UTC (Fri) by pvaneynd (subscriber, #898) [Link] (9 responses)

little in the way of ill effects is not realy the case for non-C derived environments. For example sbcl (a Common Lisp environment that compiles directly to native code) does have quite a bit of problems with all these new 'security' measures, see for instance at these instructions to get sbcl to work on FC5.

And SELinux does seem to be too complex for me to say if a certain configuration is secure or not.

non C based environments can have problems

Posted Jan 19, 2007 18:19 UTC (Fri) by janfrode (subscriber, #244) [Link] (1 responses)

> And SELinux does seem to be too complex for me to say if a certain configuration is secure or not.

As SElinux doesn't grant you any additional privileges over what you have on a non-SElinux enabled system, you should be able to say if a certain system is secure in the traditional UNIX configuration -- and additionally get the benefit other peoples work on further restricting the targeted applications. Think of it as dropping privileges, only on a system level.

non C based environments can have problems

Posted Jan 19, 2007 21:43 UTC (Fri) by pvaneynd (subscriber, #898) [Link]

I agree that SELinux is seen as an additional level of security, but some customers would quickly drop the normal unix security 'because SELinux will protect us', much like 'it is ssl encrypted' means that you don't need to pay attention to sql injection problems. Or "we don't need a firewall on the VPN link to our partner, it is encrypted!".

Not that I ever heard comments like that, of course.

Re: non C based environments can have problems

Posted Jan 19, 2007 21:03 UTC (Fri) by dododge (guest, #2870) [Link] (5 responses)

For example sbcl (a Common Lisp environment that compiles directly to native code) does have quite a bit of problems with all these new 'security' measures,

Looking at the referenced page, this doesn't seem to be a problem with the security measures so much as a rather serious design flaw in sbcl. mmap never guarantees you will get the address you ask for. Granted sbcl may have been getting lucky up to now, but it never should have required a specific mapping in the first place.

I say that as someone who has written many applications working with anything from a few megabytes to a hundred gigabytes of elaborate memory-mapped data structures, including situations where multiple threads and processes are using the data simultaneously at different mapped addresses. This sort of thing is not a problem if you design it in from the start like you're supposed to do.

Re: non C based environments can have problems

Posted Jan 19, 2007 21:29 UTC (Fri) by pvaneynd (subscriber, #898) [Link] (4 responses)

sbcl is older then you might think, it is based on cmu which started life on the pdp10, see the cmucl history. So it does things a little different from normal C programs.

Yet I fully agree that cmucl/sbcl are way "out there" on the compatibility side of things, doing stuff that is more tradition then standard. Not only the memory management is strange, they also catch SIGSEGV and friends to handle errors. They use breakpoints on themselves to do debugging and error signaling, they use write-barriers by using mprotect on pages. This has the effect that if the kernel people slow the rate at which we can accept, handle and returns from normally fatal exceptions we slow down or get random errors (like fpu flag corruption). Even libc changes can hurt us: when errno was changed from an integer variable to a macro we had to handle that with some difficulty. Changing the image to PIC is on the todo list, but with the register-starved x86 architecture nobody seems to want to dedicate a register for handling the offset for the previously constant addresses.

We accept that sometimes unforeseen (by the C users) problems can arise. And I'm not complaining, I just wanted to draw attention to the fact that non only gcc compiled programs run in Linux and that sometimes these changes hurt us.

Re: non C based environments can have problems

Posted Jan 20, 2007 22:09 UTC (Sat) by scottt (subscriber, #5028) [Link] (1 responses)

On my fedora system an implementation of the java virtual machine is labeled with the type "java_exec_t":
$ ls -Z /usr/bin/gij
-rwxr-xr-x root root system_u:object_r:java_exec_t /usr/bin/gij

Clearly sbcl want its own selinux policy module which grants it all the memory mapping priviledges it wants?

Re: non C based environments can have problems

Posted Jan 22, 2007 0:59 UTC (Mon) by dododge (guest, #2870) [Link]

If I understand the situation with sbcl, SELinux isn't even really a problem. sbcl's troubles come from other security measures aimed at buffer overflows, such as address space randomization and non-executable pages. As pvaneynd says, some old programs make assumptions about the way Unix is implemented, above and beyond what the standards guarantee. The security measures may be within the scope of the standard but they break those old assumptions and some programs just can't handle it.

Emacs Lisp is another one like this. I assume it's still using tagged pointers, which are efficient from a practical standpoint but a total abomination from a portability standpoint. A quick glance at its lisp.h suggests that it's using unions in ways that C says are undefined -- but will work due to the way most C compilers just happen to be implemented.

Re: non C based environments can have problems

Posted Jan 24, 2007 1:24 UTC (Wed) by ldo (guest, #40946) [Link] (1 responses)

...when errno was changed from an integer variable to a macro we had to handle that with some difficulty.

I think having a global errno is such a dumb idea. Why can't system and library calls directly return an error code?

...but with the register-starved x86 architecture nobody seems to want to dedicate a register...

I guess the extra registers in x86-64 must come as a relief, then. :)

Re: non C based environments can have problems

Posted Jan 24, 2007 21:13 UTC (Wed) by dododge (guest, #2870) [Link]

I think having a global errno is such a dumb idea. Why can't system and library calls directly return an error code?

Tradition.

Within the kernel, these sorts of functions typically do return error codes directly. But the userspace API is so ingrained that changing existing functions would break too much. As mentioned, even just changing errno from being a global int to a macro that produces an int (so that e.g. it can produce a different errno object for each thread) was enough to break some applications.

New APIs can of course use more sensible error reporting than errno if they want to. It could also be worse, though; for example the glibc obstack API by default aborts the program instead of returning an error, and while you can change that behavior you still have to rely on a global callback that at best uses something like setjmp/longjmp while running the risk of some library code changing the callback to something else. Yuck.

non C based environments can have problems

Posted Jan 25, 2007 19:18 UTC (Thu) by anton (subscriber, #25547) [Link]

Right. Exec-shield tripped up a sanity check in Gforth (apparently exec-shield is insane). Fortunately this was easy to fix: just comment out the check.

The tendencies of the gcc maintainers to break all non-standard code (including GNU C extensions) are a bigger problem for us.

LCA: How to improve Debian security

Posted Jan 21, 2007 15:45 UTC (Sun) by job (guest, #670) [Link]

I'm not convinced SELinux makes a system more secure; it is after all a huge body of code that none of the kernel maintainers is familiar with. How do we know it doesn't contain race conditions or overflows that can be used to escalate SELinux privileges?

There are many ACL-style capability systems beside SELinux, such as RSBAC, LIDS and grsecurity. SELinux does much more than they do, it has an elaborate system of roles that extends the user id model. Many tutorials only describe the ACL parts. But if all you want is fancy capabilities, you are probably better off with a simpler (and better understood) system.

It would surely make a good LWN article series!