LWN.net Logo

The isolate utility

The isolate utility

Posted Jan 7, 2010 7:18 UTC (Thu) by jimparis (subscriber, #38647)
Parent article: The isolate utility

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


(Log in to post comments)

The isolate utility

Posted Jan 7, 2010 14:57 UTC (Thu) by tialaramex (subscriber, #21167) [Link]

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

Posted Jan 7, 2010 17:28 UTC (Thu) by jimparis (subscriber, #38647) [Link]

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

DJB's suggestion of how to isolate a process

Posted Jan 7, 2010 19:24 UTC (Thu) by pjm (subscriber, #2080) [Link]

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

DJB's suggestion of how to isolate a process

Posted Jan 7, 2010 23:10 UTC (Thu) by drag (subscriber, #31333) [Link]

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

Posted Jan 8, 2010 11:33 UTC (Fri) by ggl (guest, #51040) [Link]

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.

Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds