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

31–40 of 101 posts

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

#31

Post by MBCook »

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.

Could you provide examples?

The stuff I'm thinking of that would plugin to Firefox or Photoshop probably do things that would already be allowed (read/write files, allocate memory, access network).

Either way this seems like an extremely simple way to lock down all the little command line utilities and small programs that make up a working unix system, so that if someone does get arbitrary command execution by other programs it gets much more difficult to chain exploits.

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

#32

Post by Demiurge »

MBCook wrote: post #29
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?

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…

IPs, DNS settings change on running programs all the time, that doesn't seem as unusual as re-opening a file that's actually not there. A unix socket is an interesting mixed case :)

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

#33

Post by eloff »

icebraining wrote: post #21
paulannesley wrote: post #20

Earlier quoted context omitted.

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.

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.

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

#35

Post by wbl »

eloff wrote: post #33
icebraining wrote: post #21

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

Privileges should be inherited across fork and monotonic down to solve this problem.

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

#36

Post by duskwuff »

Demiurge wrote: post #30
duskwuff wrote: post #28

Earlier quoted context omitted.

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?

Handles to deleted files are relatively uncommon in practice. Network sockets aren't.

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

#37

Post by sciurus »

vezzy-fnord wrote: post #18
icebraining wrote: post #17

Earlier quoted context omitted.

You can, there's a process freezing utility for Linux; I'll see if I can remember its name. EDIT: Here is it: CryoPID ( https://github.com/maaziz/cryopid ) CryoPID allows you to capture the state of a running process in Linux and save it to a file. This file can then be used to resume the process later on, either after a reboot or even on another machine.

cryopid and cryopid2 are long abandoned, possibly not working on 3.x and 4.x kernels anymore. Modern and more sophisticated equivalents are CRIU and DMTCP.

http://criu.org/Main_Page

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

#38

Post by nitrogen »

I recently asked for exactly this on StackOverflow, but for Linux[0]. Is anyone aware of an interface to seccomp-bpf on Linux that is as easy to use as this tame() syscall?

If not, does anyone want to join forces to create one? An ultra-simple library that provides tame()-like functionality on all capable platforms should make writing secure software a lot easier.

[0] https://stackoverflow.com/questions/31373203/drop-privileges... if anyone's curious

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

#39

Post by binarycrusader »

See also, Solaris' Role-Based Access Control and Privileges models.

Privileges (seems to fit the post): https://blogs.oracle.com/casper/entry/solaris_privileges

http://www.c0t0d0s0.org/archives/4075-Less-known-Solaris-fea...

Programming with Privileges Example: http://docs.oracle.com/cd/E23824_01/html/819-2145/ch3priv-25...

Overview: http://www.c0t0d0s0.org/archives/4077-Less-known-Solaris-fea...

In particular, the Solaris privileges model allows a program to gracefully degrade functionality and drop and reinstate privileges at different points of execution.

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

#40

Post by bcg1 »

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?

IIRC the Criu developers went into some detail about this on FLOSS weekly some time back:

https://twit.tv/shows/floss-weekly/episodes/334

I can't remember exactly where in the podcast they discussed it, but I believe it was just before the part where you could hear brains exploding in the background

Post reply on HN