LWN: Comments on "The isolate utility"

The isolate utility

trasz — Mon, 18 Jan 2010 11:31:58 +0000

Again, not true. Port of SELinux would be just another policy enforcement module. Existing policies work fine without it - and they have an advantage of being simple to understand.

The isolate utility

trasz — Mon, 18 Jan 2010 11:29:32 +0000

When was that, exactly? Among several things that happened in FreeBSD last year was inclusion of MAC in the default kernel and removing the "experimental" status.

The isolate utility

trasz — Mon, 18 Jan 2010 11:26:14 +0000

FreeBSD MAC, implemented as part of TrustedBSD and ported to Darwin/MacOS X,, is not a port of SELinux - it's a MAC framework and a set of modules implementing policies. Port of SELinux would be just another policy module.

The isolate utility

ggl — Fri, 08 Jan 2010 11:33:52 +0000

In his papers djb is more speaking about minimalism than blacklisting. My interpretation is that one should limit the resources that a process can access only to the needed ones.

His paper shows a develop's perspective and not how a administrator can isolate a process or prevent privilege escalation.

The isolate utility

dpquigl — Fri, 08 Jan 2010 00:43:11 +0000

They model is different than the LSM. Historically the LSM framework has been anti stacking and for some pretty good reasons. The BSD framework has every model as a separate module that can be loaded in. They have quite a few modules for a variety of functions. They have one MLS module, two integrity modules, a module to place programs in selective jail like separations called partitions, a module to protect ports, some modules for disabling network access and "firewalling" the file system. The soundness of some of the models are up for debate but they are there none the less.

The isolate utility

drag — Fri, 08 Jan 2010 00:02:55 +0000

I guess it's like Linux were you have the pluggable security module
framework were Selinux is just one of many possible frameworks.

It'll be interesting to see what evolves out of this approach.

DJB's suggestion of how to isolate a process

drag — Thu, 07 Jan 2010 23:10:09 +0000

Man the more I look at the more something like this screams out for LXC.

It does not depend on chroot. It is not complicated to setup like SELinux.
And it does not need to ran as root to manage the VM.

The isolate utility

dpquigl — Thu, 07 Jan 2010 21:34:03 +0000

I should probably rephrase this. The MLS and Biba modules weren't adequate for use without further enhancements. I didn't realize there were so many BSD MAC modules so some of them are probably production ready.

The isolate utility

martinko — Thu, 07 Jan 2010 21:21:28 +0000

MAC is no Flask/SELinux -- please read better!

http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook...

Also you may want to educate yourself what really TrustedBSD is and about it's affiliation with FreebBSD.

;-)

The isolate utility

dpquigl — Thu, 07 Jan 2010 21:15:16 +0000

Also another thing worth noting is none of the MAC modules in BSD are considered "production ready". I was looking at using the MLS module to showcase label translation in Labeled NFS and when I spoke with Robert Watson (MAC Framework/SEBSD developer) he said that the MLS implementation isn't very full featured and it is there as an example for vendors to take and extend into a more full featured implementation. Also not until FreeBSD 8.0 was the MAC framework enabled in their kernel by default. It was present in the source tree but from what I understand you needed to rebuild your kernel to enable it (mainly due to overhead concerns).

The isolate utility

dpquigl — Thu, 07 Jan 2010 21:10:08 +0000

SELinux was already ported to BSD in the form of SE-BSD which is where the MAC framework that BSD currently enjoys came from. The issue with having the SE-BSD code in the core BSD code is because of licensing issues. Some of the code needed from SELinux for SEBSD is GPL licensed which prevents it from being incorporated into the areas of FreeBSD where it is needed. I haven't looked into this very much but when considering reviving the SEBSD code for use with a BSD Labeled NFS prototype I was told the stumbling block for getting SEBSD integrated into the BSD core was to do with the license on the code.

DJB's suggestion of how to isolate a process

pjm — Thu, 07 Jan 2010 19:24:05 +0000

The quoted text is in the context of what one can get with existing UNIX tools. The paper goes on to claim that short of severe operating-system bugs, the result is that the process has no communication channels other than its initial file descriptors.

Does anyone dispute this claim, or have a better suggestion of how to implement that result with standard UNIX interfaces?

(I haven't looked into the bug mentioned, though I'd guess that isolate(1) is a world-executable setuid utility that has a bug allowing arbitrary code execution before doing the setuid step, rather than being a bug in the approach quoted from the DJB paper. Anyone who's looked into it, please either confirm or refute this guess.)

The isolate utility

jimparis — Thu, 07 Jan 2010 17:28:19 +0000

It's copied from DJB's paper, sec 5.2: http://cr.yp.to/qmail/qmailsec-20071101.pdf

The isolate utility

drag — Thu, 07 Jan 2010 15:13:30 +0000

The only mention of MAC stuff in FreeBSD's documentation is this
'TrustedBSD' stuff

http://www.freebsd.org/doc/en/books/arch-handbook/mac.html

Which is the port of Flask/SELinux from Linux to Darwin to FreeBSD.

What am I missing here?

----------------

Also the above people mis characterized SELinux as being the 'one true
framework' or whatever. There is, of course, SMACK (in since 2.6.25) and
Tomoyo, which is in since 2.6.30. Both of which are designed to be much
simpler for administrators and such to deal with.

Redhat and Fedora, of course, still focus on SeLinux, of course. Probably
because it's the most full featured solution so far and they want to meet
the requirements for a certain subset of Redhat's customers.

The isolate utility

tialaramex — Thu, 07 Jan 2010 14:57:43 +0000

It is sad to see blacklisting proposed as a security measure. Is that really from DJB? I guess everyone has blind spots.

The isolate utility

trasz — Thu, 07 Jan 2010 10:58:53 +0000

It's worth noting that everything you mentioned - various kinds of MAC policies - are already available in FreeBSD; the main difference compared to SELinux is that the FreeBSD implementation is modular, simple to understand and to maintain. That's the reason that porting SELinux to FreeBSD is stalled, I guess.

The isolate utility

jimparis — Thu, 07 Jan 2010 07:18:18 +0000

From the homepage:
"isolate currently suffers from some bad security bugs! These are local root privilege escalation bugs. Thanks to the helpful person who reported them (email Chris if you want credit!). We're working to fix them ASAP, but until then, isolate is unsafe and you should uninstall it. Sorry!"

No surprise -- the method, as inspired by DJB, is bound to fail:

"· Prohibit new files, new sockets, etc., by setting the
current and maximum RLIMIT_NOFILE limits to 0.
· Prohibit filesystem access: chdir and chroot to an
empty directory.
· Choose a uid dedicated to this process ID. This can
be as simple as adding the process ID to a base uid,
as long as other system-administration tools stay away
from the same uid range.
· Ensure that nothing is running under the uid: fork a
child to run setuid(targetuid), kill(-1,SIGKILL),
and _exit(0), and then check that the child exited
normally.
· Prohibit kill(), ptrace(), etc., by setting gid and uid
to the target uid.
· Prohibit fork(), by setting the current and maximum
RLIMIT_NPROC limits to 0.
· Set the desired limits on memory allocation and other
resource allocation.
· Run the rest of the program."

The policy of "run the program, but limit it from performing these specific bad actions" only works if you're 100% sure you covered everything bad. Forget one thing, or one new kernel feature or anything else, and you've lost...

The isolate utility

iq-0 — Wed, 06 Jan 2010 10:46:16 +0000

It even helps for deliberate ones, for a lot of attacks are based on races in file access. By locking a non-root process in a directory where it has absolutely no rights for (except for 'execute') helps limit the possible attack angles a lot by allowing less direct interactions with your environment.

Security is the sum of it's parts and no matter how evil you are, you still must exploit a weakness and anything that limits the possible weaknesses (even if it's one less) helps.

So this does help against evil even though it's not an end-all solution.

The isolate utility

drag — Wed, 06 Jan 2010 06:16:54 +0000

Oh and he never said it was not useful. It's just that if the program has
root privileges then chroot is worthless. If you do it properly with
carefully controlled file discripters and proper setuid and that sort of
thing chroot can be useful, it's just much more difficult to get right then
it seems.

In that specific mailing list discussion people are referring to is
http://kerneltrap.org/mailarchive/linux-kernel/2007/9/19/...

----

Meanwhile with things like BSD Jails, Linux LXC, or Solaris Zones are
designed to be easy for admins to make applications isolated in a proper
manner and can be used with lots of applications that would never really work
out with chroot.

The isolate utility

drag — Wed, 06 Jan 2010 05:45:37 +0000

Alax Cox's comments refer to why the fact that when people show up on the
LKML and bring up one of the obvious and blaring security defects with
Linux's Chroot implementation (and hope to see these 'problems' fixed) they
get ignored or shot down.

The isolate utility

wahern — Wed, 06 Jan 2010 03:34:33 +0000

Nice... for some limited set of apps, particularly desktop apps. Especially since it's more reasonable to expect desktop apps to be less portable than server apps. But I write server-side apps. Not only is this not especially useful on Linux servers, I still need to do sandboxing _inside_ my application both for portability, and because I still need privileges temporarily to setup my environment, such as open sockets. There're several app-specific privileged operations daemons typically need to do.

sandbox(1) uses a setuid utility. Anything which requires a setuid utility is already a red flag in my book. And such wrappers are inherently limited, anyhow.

These aren't generic solutions. They're interesting, useful, and laudable pieces of software, to be sure. But come on.... None of these things can even come close to the usefulness that traditional, portable unix privilege separation can accomplish. chroot, setuid, descriptor passing... these things are here now, ubiquitous, and time tested. Use them, developers. Security can't be an after-thought, bolted on, acceptable merely because it's described as a "security tool". The techniques needs to be tightly woven into the fabric of the code. (Alan Cox assertions are flat wrong; merely because chroot wasn't intended as a security tool doesn't mean it's not useful as such. Logic and history plainly prove him wrong, except that I personally think people take his quotes out of context anyhow.) Applications which don't do this need to be _fixed_, not amended. Additional steps, such as SELinux, VMs, etc, should be additive, not ends in themselves.

One nice thing about isolate(1) is that it uses a random UID. The code is awkward in places (I'd have just done `setuid(arc4random() | 0x80000000)', rather than a wierd loop, and anything w/ setuid mode is suspect, especially w/ all those machinations), but quite portable in theory, especially if Mach-O support could be added. And yet, at least for daemon apps, you can accomplish the same thing in about 10 lines of code if built into your app, w/o any dependencies. Sandboxing desktop apps involves special difficulties, but other than X11 and needing root privileges for chroot (I really wish systrace was built into the Linux kernel), all the same techniques apply equally well.

The isolate utility

gmaxwell — Wed, 06 Jan 2010 02:21:36 +0000

"To sandbox with SELinux I do... what?"

To sandbox? You use dan walsh's sandbox (http://danwalsh.livejournal.com/31146.html) it was linked in the very first comment here.

Yes, SELinux is complicated. It's much more expressive than chroot()+chdir(), and so it's possible to lock things in a much more find grained and secure way. The tradeoff is the complexity. Thats where tools like sandbox step in.

The isolate utility

wahern — Wed, 06 Jan 2010 00:25:22 +0000

It's difficult because it's an ad hoc process. To sandbox a daemon under unix all that need be done is chroot(path) + chdir(".") + setuid(nonrootuid). That's all in C, and generally called from the main function (my argument is for chroot(2), not for isolate(1) or chroot(1)). There are caveats, and it's no panacea, but it's straight-forward, and the user/sysadmin never need get involved. The only issue is how to make sure `path' exists. FreeBSD jail(2), which is more comprehensive, is similarly simple.

To sandbox with SELinux I do... what? To install the SELinux policies I do... what? No pithy code snippet will come close to answering that. And SELinux isn't even installed by default on Ubuntu and most other Linux distributions, not to mention other unices. Leveraging SELinux from the application perspective is difficult and clumsy. You need to create a shell scripting ecosystem to support your application. Same applies to LXC or anything similar.

RedHat might ship with default policies for Apache and BIND and similar software, but it certainly won't ship for 99% of the available applications on Freshmeat. It's nonsense to think that any single group is capable of reliably and efficiently patching, effectively, all the software out there. I say patching because though SELinux policies are text files they're nonetheless code. And that is why I say policy is indivisible from function. It's a distinction without a difference from a security perspective. They're both code.

Now, SELinux is useful in general for exactly the same reason. It allows the end-user or distributor to patch together an application by adding new code without modifying existing code. Effectively you can build custom applications, the same way a company might fork an open source project and tweak it for, say, an embedded Samba device. You can hack Samba directly and/or create SELinux policies. Yet you run into all the same problems as when you have two different groups hacking on the same software. Most prominently the maintainers of the policy end inevitably fall behind the release schedule of the main release, get tired of the treadmill, and the whole endeavor withers.

As for logging, my applications do what any good unix applications do; they log to stderr. I provide example documentation and code for attaching stderr to syslog(1) or rotatelogs(1), and my applications also make this very easy to do as a builtin operation (e.g. foo -e "|rotatelogs /var/log/foo-%Y%m%d.log"), which makes it a tad more convenient. Yes, that is in a sense leaving policy to the end-user, but the difference is that (1) I'm well aware that log processing is an application in its own right; and (2) no matter where you point stderr the daemon itself runs as securely as possible out-of-the-box. Why would I leave security up to the end-user or distributor? Who but the developer best knows how to secure his own code?

SELinux works well as an adjunct, but minimally any portable application _must_ use chroot(2). Even if something could replace chroot(2) tomorrow I'd prefer FreeBSD style jail(2) than a convoluted system that doesn't offer the possibility for a small code block in main() to provide decent sandboxing, instead requiring a haphazard process among various users--developer, distributor, admin. Theory is great, but a good solution must work in practice, and manifestly SELinux isn't a practical solution.

(I also tend to pervasively use descriptor passing between privileged and unprivileged processes. Much like chroot it's portable and, used properly, matches the security of most any other solution, and does so out-of-the-box.)

The isolate utility

drag — Tue, 05 Jan 2010 22:07:25 +0000

This page has a nice overview of LXC and how to use it to isolate a
application:

http://lxc.sourceforge.net/lxc.html

If you go to the sourceforge page it'll tell you what part of the LXC
namespace isolate got into what part of the kernel and the LWN article
discussing it. :)

With Linux 2.6.29 LXC should be fully functional.

Besides the whole isolation aspect of it you can use it for freezing and
checkpointing applications.

The isolate utility

drag — Tue, 05 Jan 2010 21:34:38 +0000

No.

If you want BSD Jail style functionality with Linux then you'll want to use LXC or use 'Vserver' or 'OpenVZ' kernel patches. These are proper things designed to compartmentalize the OS and setup light weight virtualization that is intended to be used for security reasons. LXC has the ability to create isolated PID namespaces, allow secure access to /proc. and all that sort of thing for the purpose of creating virtual machines. Allows for a high degree of application compatibility and effective can make root (running in those VMs) a unprivileged user. They are similar to the 'Solaris Containers' type thing.

As far as I can tell this project depends on chroot, which is not really a proper security tool. It never was intended to be.

The isolate utility

drag — Tue, 05 Jan 2010 21:18:58 +0000

SELinux depends on the specific configuration of the server and what you want to do with it. You can give a generic SELinux configuration, which is what Fedora and Redhat do.. but the downside of the trade offs are obvious. (Most people don't care enough to learn how to use it so they just turn it off and for people that leave it running the additional restrictions are not really that good at enhancing security).

But for the government contracts and high-security folks that Redhat (and friends) are targeting then SELinux is worth it since those additional security enhancements are things they can justify the time and expense it takes to get it done correctly for their specific needs.

All in all his post is a bit bizarre. BSD Jails is not really comparable with SELinux except to state that they are both designed to protect the system from buggy services. Other then that simularities end. Does BSD Jails provide Mandatory access controls? Role based controls? Multi level Security? No of course not. So it's a nonsensical comparison. If he wants to complain he can point out differences in how Jails work versus LXC and how traditional containers for Linux (Linux-vserver/openvz) required lots of patching and other things. Then he can go on and complain about how Solaris is using their own container virtualization and not using Jails and then complain about it with OS X and then with Windows.

That is something that would probably make sense here. But then it would be pretty simple to poke holes in it.

The reality is that if you want BSD-Jail like functionality in Linux you can have it. Easily. I've been able to get it by using 'apt-get' in Debian for probably most of the last decade (or more). People have been using stuff like that for web hosting for years and years now. Of course with LXC it's now built into the kernel and is generic enough to be used by lots of different things for different purposes.

Maybe somebody should point out the effort to get SELinux ported to FreeBSD... Wait; TrustedBSD there you go. If the FreeBSD-Jail was the all-singing and all-dancing solution to everything then why would anybody care to use anything else?

And, from a security stand point, Chroot is very bad. The worst thing about it is that administrators/developers end up trusting it to do stuff it never was intended to do.. like securing your BIND server and stuff like that. It can be done, but it's actually really difficult to do correctly since it is so fragile.

The isolate utility

jengelh — Tue, 05 Jan 2010 19:44:45 +0000

>Also, to quote Alan Cox, "chroot is not and never has been a security tool".

Yeah. How about vfsmount namespaces? (clone(2) with CLONE_NEWNS.)

The isolate utility

dpquigl — Tue, 05 Jan 2010 19:44:09 +0000

"...you can't truly separate policy from function, because they're indivisible in a security-conscious application, yet SELinux makes it very difficult to integrate policy into the development process."

Could you elaborate on this a bit? How is policy development difficult to do in parallel with the development process? Is it just that people neglect it and leave it to the end? I really don't see it being a difficult thing that when you're coding your logging code for your application that you also add the necessary policy to make sure that your program can use it and labels the files correctly.

The isolate utility

dlang — Tue, 05 Jan 2010 19:43:02 +0000

making that functionality be dependent on SELinux also means that people who want to use a different security module would have to have that module implement the same functionality or loose the capability to do this sort of thing.

this should not be dependent on SELinux any more than namespaces should be eliminated on theory that SELinux can prevent applications from accessing things they shouldn't

The isolate utility

Richard_J_Neill — Tue, 05 Jan 2010 19:38:02 +0000

> Also, to quote Alan Cox, "chroot is not and never has been a security
> tool".

Indeed. As I see it, chroot can be used to protect against accidental bugs, but not deliberate ones.

For example, a non-malicious mistake in a program could quite easily delete the wrong file. Chroot could make that file inaccessible to that process, thereby protecting it.

It's very easy to exit the chroot jail deliberately, but hard to do so inadvertently. So it's still a useful tool to protect against innocent mistakes, but not against evil.

The isolate utility

wahern — Tue, 05 Jan 2010 19:27:04 +0000

Linux would benefit from a lot of things, most importantly getting rid of its acute case of NIH syndrome. FreeBSD's kqueue and jail subsystems are two good examples.

It took about seven years for Linux to finally get signalfd, relative to when kqueue debuted. dnotify and inotify!? Perhaps Linux's interfaces are marginally superior, but was it worth the wait and portability hassles? And kqueue still provides features unavailable in Linux.

The same analysis could apply to FreeBSD-style jails, except it looks like SELinux will be the final solution nobody uses. And the reason SELinux sucks is obvious; you can't truly separate policy from function, because they're indivisible in a security-conscious application, yet SELinux makes it very difficult to integrate policy into the development process.

This is why jail(2) and even chroot(2) are so powerful and so much more preferable than all the other convoluted solutions out there.

The isolate utility

dtlin — Tue, 05 Jan 2010 18:34:35 +0000

While this is hosted on Google Code, I see no indication that this is a
Google project. Do you?

The isolate utility

Tet — Tue, 05 Jan 2010 18:12:27 +0000

Google seem to be reinventing the wheel far too much of late. Under Linux, you can already do this with an SELinux sandbox, or you could use systrace (which also works under other Unix variants). Also, to quote Alan Cox, "chroot is not and never has been a security tool". Yes, isolate does more than just use chroot(), but still... I think I'll stick with the SELinux sandbox.

The isolate utility

brouhaha — Tue, 05 Jan 2010 17:38:00 +0000

There's been a Linux implementation of the BSD Jail functionality for many years, though it was never merged. Is this better?

The isolate utility

skx — Tue, 05 Jan 2010 17:16:43 +0000

It does need some fiddling to work on 64-bit systems, but its a cute implementation.

The isolate utility

drag — Tue, 05 Jan 2010 17:10:10 +0000

I wonder if a project like this would benefit from LXC. http://www.ibm.com/developerworks/linux/library/l-lxc-containers/

Just because although Chroot is used all the time to isolate processes it is not terribly difficult to break out (especially if anything is running with root privileges) of one since it is not really designed for security.. where as container-style approaches to virtualization are intended to isolate everything; including root access.

similarly

nteon — Tue, 05 Jan 2010 17:02:10 +0000

there is also the excellent Rainbow, originally developed for the OLPC project.

sandboxing.org

mstone — Tue, 05 Jan 2010 16:35:41 +0000

A more comprehensive overview of this field can be found at sandboxing.org. While visiting, be sure to check out the mailing list, sandboxing-talk@lists.sandboxing.org, which is an excellent venue for questions about isolation technology.

The isolate utility

cesarb — Tue, 05 Jan 2010 16:13:09 +0000

Another option is Dan Walsh's sandbox -X.