LCA: How to improve Debian security
![[Russell Coker]](https://static.lwn.net/images/conf/lca2007/RussellCoker-sm.jpg)
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 |
Posted Jan 18, 2007 11:19 UTC (Thu)
by ekj (guest, #1524)
[Link] (1 responses)
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.
Posted Jan 18, 2007 16:21 UTC (Thu)
by nix (subscriber, #2304)
[Link]
Posted Jan 18, 2007 18:23 UTC (Thu)
by JoeBuck (subscriber, #2330)
[Link]
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.
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.
Posted Jan 19, 2007 18:19 UTC (Fri)
by janfrode (subscriber, #244)
[Link] (1 responses)
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.
Posted Jan 19, 2007 21:43 UTC (Fri)
by pvaneynd (subscriber, #898)
[Link]
Not that I ever heard comments like that, of course.
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.
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.
Posted Jan 20, 2007 22:09 UTC (Sat)
by scottt (guest, #5028)
[Link] (1 responses)
Clearly sbcl want its own selinux policy module which grants it all the memory mapping priviledges it wants?
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.
Posted Jan 24, 2007 1:24 UTC (Wed)
by ldo (guest, #40946)
[Link] (1 responses)
I think having a global errno is such a dumb idea. Why can't system and library calls directly return an error code?
I guess the extra registers in x86-64 must come as a relief, then. :)
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
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.
Posted Jan 25, 2007 19:18 UTC (Thu)
by anton (subscriber, #25547)
[Link]
The tendencies of the gcc maintainers to break all non-standard code (including GNU C extensions) are a bigger problem for us.
Posted Jan 21, 2007 15:45 UTC (Sun)
by job (guest, #670)
[Link]
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!
In theory stuff ougth to be more secure with more fine-grained security.LCA: How to improve Debian security
A good few Debian developers of my acquaintance agree with you...LCA: How to improve Debian security
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:
VMS had an interesting approach to capabilities
Privileges fall into the following seven categories according to the damage that the user possessing them could cause the system:
non C based environments can have problems
> 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
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!".non C based environments can have problems
Re: non C based environments can have problems
Re: non C based environments can have problems
On my fedora system an implementation of the java virtual machine is labeled with the type "java_exec_t":Re: non C based environments can have problems
$ ls -Z /usr/bin/gij
-rwxr-xr-x root root system_u:object_r:java_exec_t /usr/bin/gij
Re: non C based environments can have problems
Re: non C based environments can have problems
...when errno was changed from an integer variable to a macro we had to handle that with some difficulty.
...but with the register-starved x86 architecture nobody seems to want to dedicate a register...
Re: non C based environments can have problems
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.
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.
non C based environments can have problems
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?LCA: How to improve Debian security