Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A subsystem to restrict programs into a “reduced feature operating model”

marc.info

Post reply on HN
Print view View original

21–30 of 101 posts

Re: A subsystem to restrict programs into a “reduced feature operating model”

#21

Post by icebraining »

paulannesley wrote: post #20
wmf wrote: post #15

Earlier quoted context omitted.

I think the OpenBSD philosophy is to run plugins in separate processes.

I'd presume child processes would inherit the same restrictions as the parent process. I guess a root process could remain privileged, the main restricted process could be a child of that, and that main process could ask the root process to spawn plugins. But, that'd weaken the model a bit.

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.

Re: A subsystem to restrict programs into a “reduced feature operating model”

#22

Post by geofft »

This doesn't seem particularly better than Linux's seccomp-bpf or OS X's seatbelt. In particular, I don't really understand the complaint about not wanting to write a program, then turning around and writing a system call, running with full privilege on the system, that hardcodes all sorts of things about userspace.

I wish he'd acknowledge and discuss prior, effective work in this space instead of saying things "showed up" and they're "insane". For instance, a direct comparison to either seatbelt or seccomp-bpf would make it clear that the distinction between initialization vs. steady state is well-explored in production systems using this (like sandboxed Chrome renderers) and not novel.

Re: A subsystem to restrict programs into a “reduced feature operating model”

#23

Post by comex »

geofft wrote: post #22

This doesn't seem particularly better than Linux's seccomp-bpf or OS X's seatbelt. In particular, I don't really understand the complaint about not wanting to write a program, then turning around and writing a system call , running with full privilege on the system, that hardcodes all sorts of things about userspace. I wish he'd acknowledge and discuss prior, effective work in this space instead of saying things "sho…

The implementation is better than OS X, because OS X has a ton of kernel API surface available to userland and much of it can't even be sandboxed, while tame starts with one syscall and works its way up.

I agree it's not better than seccomp-bpf plus a library to supply these kinds of common policies in userland, with the caveat that I don't know of any such library in common use on Linux.

Re: A subsystem to restrict programs into a “reduced feature operating model”

#24

Post by geofft »

comex wrote: post #23
geofft wrote: post #22

This doesn't seem particularly better than Linux's seccomp-bpf or OS X's seatbelt. In particular, I don't really understand the complaint about not wanting to write a program, then turning around and writing a system call , running with full privilege on the system, that hardcodes all sorts of things about userspace. I wish he'd acknowledge and discuss prior, effective work in this space instead of saying things "sho…

The implementation is better than OS X, because OS X has a ton of kernel API surface available to userland and much of it can't even be sandboxed, while tame starts with one syscall and works its way up. I agree it's not better than seccomp-bpf plus a library to supply these kinds of common policies in userland, with the caveat that I don't know of any such library in common use on Linux.

Yeah, seatbelt is not that compelling in practice, but that's true of the OS X kernel/userspace boundary in general. :/ But the design of it seems to match what's wanted here, exactly: you can enable restrictions during the running of a process, and OS X ships with a handful of standard seatbelt profiles.

pcwalton's gaol, which has both seccomp-bpf and seatbelt backends, has a concept of "profiles," which I think matches the general idea here:

https://github.com/pcwalton/gaol

To be fair I wouldn't use it in production yet, but it's quite a bit more reviewed than tame(2) is right now.

Re: A subsystem to restrict programs into a “reduced feature operating model”

#25

Post by Demiurge »

thorwafspp wrote: post #11
TheLoneWolfling wrote: post #10

Earlier quoted context omitted.

On an unrelated note, but tangential to your link, why can I not save and restore processes? It seems like something that would be relatively easy to do - suspend all threads, save the thread control blocks, mark all pages as fault-on-write, resume threads, and start saving pages, unmarking them once they are saved. If/when a thread faults, copy (or save immediately) that page and then resume that thread. (Or potenti…

You've tickled on the problem but not quite nailed it. > You need to deal with file handles / etc, but that can be done too. That's actually the hard part. To get a real image of that process in time, you need to snapshot the full filesystem state, too. Or it could change out from beneath your program. Even more complicated: network state.

Why is network more complicated? I would think network doesn't have any atomic/uninterruptible states filesystem might?

Re: A subsystem to restrict programs into a “reduced feature operating model”

#26

Post by yk »

obstinate wrote: post #14
wfunction wrote: post #12

This won't work for programs that allow for plugins, which are arguably those that need the most protection. Programs don't generally know what permissions plugins when they are compiled.

Hrm. I don't see why not? The plugin declares its behaviors in a manifest. During program initialization, the program reads all the manifests, sums the permissions, and declares those. Of course, if you download an infected plugin, you're going to have a bad time. But that is likewise a problem if you download an infected program and run it. It's not an attack vector this syscall is meant to prevent.

I don't think that the plugin should declare it's behavior. Consider the case were you have a shared webserver and a php-plugin for one user (say a wordpress installation). Then the user ( or anyone with write access to the user directory) can control the permissions of the server.

On the other hand, a well designed plugin interface could set default permissions. For example the plugin interface could have a SQL method, so that a plugin does not need to talk to a socket directly.

Re: A subsystem to restrict programs into a “reduced feature operating model”

#28

Post by duskwuff »

Demiurge wrote: post #25
thorwafspp wrote: post #11

Earlier quoted context omitted.

You've tickled on the problem but not quite nailed it. > You need to deal with file handles / etc, but that can be done too. That's actually the hard part. To get a real image of that process in time, you need to snapshot the full filesystem state, too. Or it could change out from beneath your program. Even more complicated: network state.

Why is network more complicated? I would think network doesn't have any atomic/uninterruptible states filesystem might?

If a process has a stream socket open to another process, or to another system over the network, what happens to that socket when the process is "thawed"?

How about if it's listening on a TCP port -- what happens if that port is in use by another process when the original one is thawed?

Re: A subsystem to restrict programs into a “reduced feature operating model”

#29

Post by MBCook »

Demiurge wrote: post #25
thorwafspp wrote: post #11

Earlier quoted context omitted.

You've tickled on the problem but not quite nailed it. > You need to deal with file handles / etc, but that can be done too. That's actually the hard part. To get a real image of that process in time, you need to snapshot the full filesystem state, too. Or it could change out from beneath your program. Even more complicated: network state.

Why is network more complicated? I would think network doesn't have any atomic/uninterruptible states filesystem might?

It's easy to re-open a file (assuming it's still there), but with sockets your IP may have changed, the remote IP may have changed (which you may have stored in your working memory that got checkpointed), DNS may point you to a different service entirely, you could have had to do some kind of port knocking or something to get that connection open in the first place.

I know this kind of stuff is being worked on so VMs/containers/namespaces can be moved around but it seems to be one of those things that gets really complicated when you try to do it transparently for userspace.

Re: A subsystem to restrict programs into a “reduced feature operating model”

#30

Post by Demiurge »

duskwuff wrote: post #28
Demiurge wrote: post #25

Earlier quoted context omitted.

Why is network more complicated? I would think network doesn't have any atomic/uninterruptible states filesystem might?

If a process has a stream socket open to another process, or to another system over the network, what happens to that socket when the process is "thawed"? How about if it's listening on a TCP port -- what happens if that port is in use by another process when the original one is thawed?

I understand this can't go 'right', but are those things more difficult than filehandles to files that have been deleted?
Post reply on HN