Security in the 20-teens

Posted Feb 1, 2010 21:09 UTC (Mon) by cmccabe (guest, #60281)
Parent article: Security in the 20-teens

I read an interesting paper recently by the author of qmail. It's here:
http://cr.yp.to/qmail/qmailsec-20071101.pdf

Basically, he claims that our existing approaches to security have failed. "Chasing attackers" by closing security bugs once they're published will never really result in a secure system; programmers just keep adding new bugs as the old ones are found. Firewalls, virus scanners, and other "band aids" don't really fix the underlying security problems, and just add a new layer of complexity for system administrators.

More controversially, he claims that restricting privilege is not as worthwhile as is generally thought. I'm not sure if I completely agree with this, but I will say one thing. In the absence of a LSM, the privileges of a process running as you are pretty high! It can read everything in your home directory, add code to your .bashrc, send messages over DBus, etc. From the perspective of an attacker, /home is where the good stuff is, and not having root may not really be a big deal.

Bernstein's proposed solution is to minimize the amount of "trusted code" by putting most of the program in some kind of sandbox. Using seccomp or running software in a virtual machine are two ways to sandbox code. He also wants to minimize the overall amount of code, to make it more auditable.

Generally, sandboxing code involves restructuring a program in terms of multiple processes that communicate over some IPC channel. This has some other advantages, since we're soon going to be living in a world of 64 or 128-core consumer CPUs. Programmers who really care about performance need to start thinking about parallelism anyway.

Sanboxing

Posted Feb 1, 2010 22:09 UTC (Mon) by jamesmrh (guest, #31622) [Link] (5 responses)

It seems we can accomplish a lot with sandboxing.

With the SELinux sandbox, the default rules for any app running inside are essentially to deny all accesses (e.g. no access to the filesystem, except to load shared libraries, no networking etc.), and we then pass an open file descriptor to the sandbox, over which all communication operates.

This means that the calling program assigns all authority to the sandbox via the open fd, and the sandbox has no "ambient" authority. It's quite a powerful abstraction and we can build more around it (e.g. sandbox X runs graphical apps via a nested X server, communicating over an fd).

See:

- http://video.linuxfoundation.org/video/1565
- http://namei.org/presentations/selinux-sandboxing-fossmy2...

These principles can be applied to other distros/security models.

There's an emerging area of research around the concept of removing ambient authority, see:

http://en.wikipedia.org/wiki/Object-capability_model

We're limited somewhat in Linux by the underlying design of the OS, but as above, we can apply some of the principles.

Sanboxing

Posted Feb 1, 2010 23:15 UTC (Mon) by cmccabe (guest, #60281) [Link] (4 responses)

The seLinux sandbox looks promising. For some reason, policycoreutils doesn't include the "sandbox" program for me in Fedora Core 11. It must have been added after the distro was released.

Maybe this is a dumb question, but are there any plans to sandbox apps "by default" in the future? Or is the goal to ship SELinux policies that are restrictive enough to contain misbehaving processes running as the local user? One of the points that was advanced in favor of seccomp was that there's no "off switch" like there is for seLinux.

Sanboxing

Posted Feb 2, 2010 0:35 UTC (Tue) by jamesmrh (guest, #31622) [Link] (1 responses)

It's a Fedora 12 feature.

I think it'd be useful to transparently sandbox some applications, and then perhaps break the sandbox if the user initiates an action which requires access outside.

e.g. all pdf viewing is sandboxed by default, but if the user wants to save the file, the sandbox is disabled for that access (need to ensure that the user clicked save w/ trusted path). Complex apps like firefox are more difficult, but not impossible.

One of the points that was advanced in favor of seccomp was that there's no "off switch" like there is for seLinux

Disabling SELinux can be prevented (modulo kernel bugs).

Sanboxing

Posted Feb 2, 2010 10:02 UTC (Tue) by nix (subscriber, #2304) [Link]

But about half the security holes on a Linux system *are* kernel bugs, and they're particularly nasty to fix because they require a reboot (which almost no other security fix does). So all an attacker waiting to own a system has to do is wait until a vulnerability window opens but you haven't rebooted, and then attack. Brad Spengler has demonstrated just how fast an exploit can be whipped up in that situation by someone with sufficient skill (and I'm quite certain major governments employ a good few such people).

Sanboxing

Posted Feb 2, 2010 16:10 UTC (Tue) by mjthayer (guest, #39183) [Link] (1 responses)

A dumb follow-up question, but one that has been on my mind for a while: are there any (more or
less) simple ways a *user* process can drop its privileges and enter a sandbox voluntarily without
using something as heavy duty as SELinux? Like setting the RLIMIT_NOFILE hard limit to one after it
has opened all files and sockets it needs? I am assuming of course that it is a true user process,
not setuid root or whatever.

Sanboxing

Posted Feb 2, 2010 18:52 UTC (Tue) by drag (guest, #31333) [Link]

Use LXC.

I can setup a LXC container as root that then can be safely used by users.
This is done through Linux file capabilities and does not require any
setuid programs or anything to be done.

It's as simple as running 'debootstrap' in a directory, installing firefox
into it, and then setting up a lxc configuration.

From then on users can execute firefox from that environment, using their
own UIDs and such, and have the output passed to Xephyr or to their own X
server.

I've done it. It works, it is fast, and unlike chroot it does not require
root rights and is designed for security. It has various levels of
isolation you can setup.

Unlike SELinux it's easy to understand and for mortals to understand.

Security in the 20-teens

Posted Feb 2, 2010 16:12 UTC (Tue) by dgm (subscriber, #49227) [Link] (1 responses)

I think that the most important (and also most overlooked) point made by Berstein is that complexity is the enemy of security. Only simple enough systems can be made secure. Sandboxing may help sometimes, but is just a ban-aid. What we need is simpler systems that we can write without bugs.

Security in the 20-teens

Posted Feb 11, 2010 9:22 UTC (Thu) by renox (guest, #23785) [Link]

>What we need is simpler systems that we can write without bugs.

Need? For security perhaps but history has shown that ,as time goes by, we use systems which have more and more features which is hard to reconciliate with the need for simpler systems..

Security in the 20-teens

Posted Feb 4, 2010 8:55 UTC (Thu) by eric.rannaud (guest, #44292) [Link]

> Bernstein's proposed solution is to minimize the amount of "trusted code"
> by putting most of the program in some kind of sandbox. Using seccomp or
> running software in a virtual machine are two ways to sandbox code. He
> also wants to minimize the overall amount of code, to make it more
> auditable.

I would like to remind everyone that it is exactly how Google Chrome
behaves (or Chromium the open source version that runs on Linux), using
seccomp.

All the HTML parsing, Javascript interpretation, image rendering, page
rendering happens in a very tight sandbox. A vulnerability in a PNG library
will not result in a breach of the system. Firefox does nothing of the
sort, quite sadly.

Chrome is the web browser the OpenBSD project would have designed. It
relies on privilege separation everywhere (and a sandbox on top of that, to
limit the impact of OS-level security flaws, like a buggy syscall). Its
design is similar to OpenSSH.

This is the right model. A PDF viewer should be designed that way, as well
as an email client. In this context, so-called webapps become counter-
intuitively *more* secure than local apps that run with $USER privileges.
And remember than with HTML5 localStorage, so-called webapps don't actually
have to store your data with a remote server. Webapps are not usually
designed that way, but they could. And there is of course NaCl, a Google
browser plugin that can run native applications in a sandbox.

It is certainly quite ironic that Google was apparently attacked through
either an IE flaw or an Acrobat Reader flaw. By design, Google Chrome is
more secure against the first class of attacks, and there has been talk of
adding a sandboxed native PDF renderer to Chrome, but that hasn't been done
yet...

See http://dev.chromium.org/chromium-os/chromiumos-design-doc...
overview and LWN's http://lwn.net/Articles/347547/

NB: Google Chrome is now available on Linux. For yum users, follow the
instructions at http://www.google.com/linuxrepositories/yum.html and:
yum install google-chrome-unstable