Great to see another attempt at this model. I do like capsicum (seems pretty straightforward), but it seems like it can require some added complexity with things like casperd for dns.
Very interested to see how this works out.
A subsystem to restrict programs into a “reduced feature operating model”
51–60 of 101 posts
Re: A subsystem to restrict programs into a “reduced feature operating model”
#52This is pretty brilliant/obvious in hindsight. In addition to the sandboxing protection, you also have a really good inventory of what privileges the application requires. Looking over the diffs in the applications - most of them are two or three lines - a #include followed by something simple like tame(TAME_STDIO | TAME_DNS | TAME_INET);
What I really like about a lot of the OpenBSD initiatives, is they don't overthink their solutions - they make them as simple as possible, but no simpler. Signify, which avoided the entire web-of-trust/PKI complication is another example.
Re: A subsystem to restrict programs into a “reduced feature operating model”
#53Earlier quoted context omitted.
I think it makes sense for child plugins to inherit restrictions at the time of the fork , not indefinitely. So the main process could spawn its plugins, then drop its own privileges.
But then you can just fork() and run your exploit in the child process after it raises is permissions. I don't see how that could work.
The unixy solution to this is rather obvious. Main app runs at relatively-higher privilege. Main app forks proc for plugin. Drops privilege in the child after the fork. Then calls exec on the plugin. The plugin is stuck at that lower privilege, but still talks to the main app through a pipe etc.
Re: A subsystem to restrict programs into a “reduced feature operating model”
#54This interface makes a system call at run time to reduce privileges. I wonder if there is a way to do this statically and automatically, either with some header file magic, or by analyzing the symbols in the executable: just assume at link time that any system calls it makes (and only those) are allowed.
well, if it can create new address space mappings, it can simply create a new text mapping and execute the call from there.
If anything, the place to implement it statically could be either a virtual machine jit, or at the compilation stage.
Re: A subsystem to restrict programs into a “reduced feature operating model”
#55I can't see where in this patch forked children inherit the `ps_tame` from the parent process. I don't know this kernel at all but it seems like something like this should be in sys/kern/kern_fork.c pr->ps_tame = parent->ps_tame Otherwise tamed processes could just fork a process to do things they've declared that they won't do.
Note that about half of the parent proc struct is simply copied into the child.
Re: A subsystem to restrict programs into a “reduced feature operating model”
#56I can't see where in this patch forked children inherit the `ps_tame` from the parent process. I don't know this kernel at all but it seems like something like this should be in sys/kern/kern_fork.c pr->ps_tame = parent->ps_tame Otherwise tamed processes could just fork a process to do things they've declared that they won't do.
Note that about half of the parent proc struct is simply copied into the child.
Ah yeah, just found that, the patch has a couple lines added to sys/proc.h,
+ u_int ps_tame;
+
Makes sense now.
Re: A subsystem to restrict programs into a “reduced feature operating model”
#57Earlier quoted context omitted.
A tamed process cannot even call fork(2) unless the TAME_PROC flag is passed, in which case I'd assume the child process would then inherit a copy from the parent as part of a normal fork(2) operation. It can be later revoked by the child, but it may want to keep it for kill(2).
I'm `cvs get`ting as fast as I can to read the rest of sys_fork.c to sate my curiosity, but CVS incredibly slow. I'm spoiled by how git packs the repo.
turned out to be way faster just to grab http://mirrors.sonic.net/pub/OpenBSD/5.7/sys.tar.gz , if anybody else wants to poke around and doesn't want to wait for cvs.
Re: A subsystem to restrict programs into a “reduced feature operating model”
#58Earlier quoted context omitted.
A tamed process cannot even call fork(2) unless the TAME_PROC flag is passed, in which case I'd assume the child process would then inherit a copy from the parent as part of a normal fork(2) operation. It can be later revoked by the child, but it may want to keep it for kill(2).
I'm `cvs get`ting as fast as I can to read the rest of sys_fork.c to sate my curiosity, but CVS incredibly slow. I'm spoiled by how git packs the repo.
Sounds like you're doing something unnecessarily more complicated than this:
$ time cvs -d anoncvs@anoncvs1.ca.openbsd.org:/cvs export -rHEAD src/sys/kern/kern_fork.c
U src/sys/kern/kern_fork.c
0m2.73s real 0m0.06s user 0m0.04s systemRe: A subsystem to restrict programs into a “reduced feature operating model”
#59So, do I have it right that this is effectively a way of a program being able to declare to the operating system "I shouldn't ever do "? Because, if so, that makes a whole lot of sense. (Adding security "for free" generally does). This could conflict with on-the-fly upgrades, though. If it turns out that some later version of your program does in fact require , then you'll have to kill and restart the process as oppo…
If you read through the examples, it's even better. The default case when you call tame() is that you don't get any privileges, so you explicitly have to call and declare to the operating system, "I need to be able to do - don't let me do anything else."
Re: A subsystem to restrict programs into a “reduced feature operating model”
#60Having fine-grained capabilities and the ability to turn them off is always useful. The usual problem is that some component needs to, say, open a file, so all code gets "open file" privileges.
There's a tool like this for Android phones. It not only can turn privileges off for an application, but also offers the option to provide apps fake info for things they don't need. You can, for example, deny address book access; if the app tries to access the address book, it gets a fake empty one. You can deny camera access; the app gets some canned image. This allows you to run overreaching apps while keeping them from overreaching.