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

11–20 of 101 posts

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

#11

Post by thorwafspp »

TheLoneWolfling wrote: post #10
vezzy-fnord wrote: post #4

For another example of a similarly beautiful interface that echoes "difficult solution made stupidly simple to use", checkpointing under DragonFly BSD: http://leaf.dragonflybsd.org/cgi/web-man?command=sys_checkpo... On an unrelated note, I've always had respect for how Theo de Raadt is both the project leader of a complete BSD system, yet also an active hacker. Contrast to Linus Torvalds, who's mostly a manager nowad…

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.

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

#13

Post by icebraining »

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.

I don't see why this would need to be known at compile time. You could load the plugins, ask them what they need, then drop everything else.

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

#14

Post by obstinate »

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.

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

#15

Post by wmf »

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.

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

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

#17

Post by icebraining »

TheLoneWolfling wrote: post #10
vezzy-fnord wrote: post #4

For another example of a similarly beautiful interface that echoes "difficult solution made stupidly simple to use", checkpointing under DragonFly BSD: http://leaf.dragonflybsd.org/cgi/web-man?command=sys_checkpo... On an unrelated note, I've always had respect for how Theo de Raadt is both the project leader of a complete BSD system, yet also an active hacker. Contrast to Linus Torvalds, who's mostly a manager nowad…

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

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

#18

Post by vezzy-fnord »

icebraining wrote: post #17
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 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.

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

#19

Post by adrusi »

TheLoneWolfling wrote: post #7

So, 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…

It can also be used by a parent process to limit the functionality of a child process, by calling tame() after fork() and before exec(). I can imagine this being used with some a "tame" command in the shell to run untrusted programs. Of course I don't know how thorough the sandboxing is, and I wouldn't trust it to make unsafe programs completely safe.

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

#20

Post by paulannesley »

wmf wrote: post #15
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.

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.

Post reply on HN