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

81–90 of 101 posts

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

#81

Post by Athas »

adrusi wrote: post #19
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.

> I can imagine this being used with some a "tame" command in the shell to run untrusted programs.

This might not be useful in practice. The inspiration behind tame() is the observation that a program usually needs many more rights at initialisation-time than in its main-loop. Thus, tame()ing a program before it even starts is unlikely to be practical - if you give it enough permissions to successfully start (including whatever is needed for dynamic linking), you may not have reduced its capabilities much.

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

#82

Post by TazeTSchnitzel »

raverbashing wrote: post #70
Animats wrote: post #60

Having 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 acce…

Yeah, for 'open file' kind of stuff it would be better to have a real sandbox (I think Windows began doing something like this, not sure if in Vista or 7, that if programs wanted to write to certain restricted places they can - but this is written to their sandbox, so if they read it later they can get the files but with no effect on the system files)

Vista did that as a compatibility workaround. Older Windows apps from the 9x and XP era were used to being run as Administrator and being able to write directly to Program Files and the like. In order to make some of these work on Vista without running them as Administrator, the solution was to lie to the applications and make their writes go through to sandboxes instead.

The sandboxing was flawed, though. It causes problems for some applications. For example, Gang Garrison 2, a game I have worked on, fails to update itself if stuck in Program Files and not run as admin.

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

#84

Post by Mordak »

SloopJon wrote: post #41

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

Looking at a program statically and limiting its privileges automatically would be good (autotame?), but it misses the point that tame appears to be trying to solve. Specifically, it is often the case that programs need more privilege once at initialization time, and less privileges later. So at startup, your program needs to open some files, and open listening network sockets, etc., but once initialization is done it just needs CPU. A static analysis would see that the program opens files and listening sockets and stuff, and grant those privileges forever. If you want to capture the reduced privileges required after the one-time initialization then you need to modify the program to use something like tame (or capsicum, etc.).

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

#85

Post by SFjulie1 »

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.

Most of the issues with firefox, drupal, whatever are coming from plugins anyway.

Protocol based interactions (that requires clear API) do a better job at isolation than modules.

In a certain way linux too the obligation for drivers to be runned kernel space and thus the adaptation made for drivers to access resources have made some part of the kernel internal API klugish. On the other way, it is true that the use of modules without API enables linux to present an external API that does not change while you can modify the behaviour of the kernel and its internal.

(I guess there is a price to pay for everything, but not everybody is a genius like Torvalds)

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

#86

Post by gnuvince »

MichaelCrawford wrote: post #63

A simple easy way to keep a lid on privelige escalation is to remove all the files that you computer does not absolutely require to do its job. Especially the development tools: the Morris worm enabled portability by distributing itself in source code form then building its binary on its target hosts. My sister once read a novel about some very traditional, strictly religious people who fastened their shirts with str…

> A simple easy way to keep a lid on privelige escalation is to remove all the files that you computer does not absolutely require to do its job.

Taken to its logical conclusion, you sort of end up with a unikernel system, like Mirage OS[1]: only the code necessary for the execution of the service is compiled into the kernel. These systems don't even have a shell.

[1] https://mirage.io

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

#87

Post by brynet »

SFjulie1 wrote: post #83

Let's say I received a SIGHUP and I need to reload my configuration after I dropped my right for reading /etc/ and all the syscall for provisioning my resources. How screwed am I?

You would have a parent process that retains permissions to read configuration and sends changes to children, i.e: imsg_*(3) on OpenBSD.

http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man3/...

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

#88

Post by stsp »

Pyxl101 wrote: post #71
philsnow wrote: post #61

Earlier quoted context omitted.

Yep, I was grabbing `src` instead of `src/sys/kern/kern_fork.c`. I've completely forgotten how to CVS, and I'm okay with that.

What are the reasons why CVS is still in use?

Because we're already too busy with porting our code base to Ruby.

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

#89

Post by stefanha »

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…

I agree, this isn't particular new or inspired. It's similar to existing mechanisms which the author pointed out.

Seccomp is really hard to integrate into existing programs, especially if they are monolithic and don't have privilege separation already. You can't narrow down the syscall footprint in complex programs enough to get decent protection unless you already have something along the lines of privilege separation. Third party libraries cause headaches too because their syscall footprint might conflict (now or in the future!) with the main program's seccomp configuration.

Capsicum looks interesting. The challenge with fancy security mechanisms is that many people contributing to the codebase may be unaware or care only about use-cases where fine-grained capabilities aren't needed.

At the end of the day, all these mechanisms can work well but it's best to use them from the start and make them one of the key concerns that all developers know about.

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

#90

Post by tene »

raverbashing wrote: post #70
Animats wrote: post #60

Having 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 acce…

Yeah, for 'open file' kind of stuff it would be better to have a real sandbox (I think Windows began doing something like this, not sure if in Vista or 7, that if programs wanted to write to certain restricted places they can - but this is written to their sandbox, so if they read it later they can get the files but with no effect on the system files)

This exists today, with selinux sandbox.

http://linux.die.net/man/8/sandbox

Post reply on HN