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

91–100 of 101 posts

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

#91

Post by dllthomas »

duskwuff wrote: post #36
Demiurge wrote: post #30

Earlier quoted context omitted.

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.

"Handles to deleted files are relatively uncommon in practice."

Could you please expand on your reasoning here? We're talking about restoring processes at arbitrary points in the future. That means we're not just talking about handles to files that were deliberately deleted while the process was running, but also anything that the process had open that was frozen that may have been subsequently deleted. That would seem to include any log file that gets rotated, which is not exactly rare, plus a ton more things.

I also think that treating network sockets as if they were disconnected is likely to go better than treating files that way - existing programs probably make more assumptions about disk state not changing unexpectedly than about network state not changing unexpectedly (even if both are technically not well founded).

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

#92

Post by TheLoneWolfling »

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.

Elaborate? I don't think there's much of anything that could change out from under a suspended process that couldn't change out from under a running process.

(Case in point: you can have a system hibernate, have a supposedly locked file change, and have the system resume.)

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

#94

Post by strcat »

stefanha wrote: post #89
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 separati…

The tame call isn't far from being an extremely coarse version of seccomp. In general, both require splitting up programs into components to implement a sandbox. Otherwise, they're only able to reduce the kernel attack surface for an existing sandbox and not nearly as much as they could if it was split up well. They're both vulnerable to changes in third party libraries and don't have control over filesystem access once those system calls are allowed (it's all or nothing, beyond tame's hard-wired paths).

The main missing feature on Linux is the ability for programs to apply their own path-based MAC policy as seccomp can't be used to do string comparisons and couldn't realistically be extended to offer it. It's one of the main reasons that robust seccomp sandboxes require so much work.

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

#95

Post by strcat »

caf wrote: post #78
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…

You might well be able to implement tame() entirely in userspace using seccomp-bpf.

You can almost do it, but you can't whitelist paths. Luckily, none of the hard-wired paths is particularly compelling. With either feature, you end up needing a multi-process architecture as soon as you want to allow access to certain paths in a sandbox. It's just that tame hard-wired a few used by the base system, but they aren't generally useful outside of it.

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

#96

Post by strcat »

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.

I don't think it would be particularly useful. The most common usage of seccomp is hardening an existing sandbox by reducing kernel attack surface. Fine-grained control is crucial for that, since it's the entire point. Every unnecessary system call or permitted system call flag is added attack surface.

When seccomp is actually being used to implement the sandbox semantics, the application usually needs to be designed around it. It's very difficult to apply it this way to an existing application. I just don't think there's a strong use case for coarse control when it's so far from being the real hard problem.

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

#97

Post by MichaelCrawford »

gnuvince wrote: post #86
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

Many embedded systems are that way.

While it is helpful that hardware memory management will protect against erroneous and malicious code, even better is for the code to be correct and ethical.

This because the MMU hardware takes up power, it costs money, generates heat and uses real estate. Also the software is complex and uses a lot of memory for page tables and complex allocation schemes.

The Oxford Semiconductor 911, 912 and 922 didnt even have a kernel nor did they have dynamic memory allocation, just stack and static memory with an infinite loop operating a state machine. A huge PITA to debug but the memory and flash were quite cheap because there werent very much of either.

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

#98

Post by eloff »

asveikau wrote: post #53
eloff wrote: post #33

Earlier quoted context omitted.

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.

That's how you should do it, yes. But the OP was talking about increasing privs in the forked process, which would defeat the security.

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

#99

Post by asveikau »

eloff wrote: post #98
asveikau wrote: post #53

Earlier quoted context omitted.

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.

That's how you should do it, yes. But the OP was talking about increasing privs in the forked process, which would defeat the security.

And my point is nobody who knows what they are doing would build it that way. Nobody suggested it ever work that way. OP's doubt on the subject was rooted in a misunderstanding of unix philosophy.

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

#100

Post by icebraining »

eloff wrote: post #98
asveikau wrote: post #53

Earlier quoted context omitted.

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.

That's how you should do it, yes. But the OP was talking about increasing privs in the forked process, which would defeat the security.

Who, me? No, I wasn't. I was talking about the plugins keeping the high privileges (not raising them). And that would be because I assumed the plugins, like the main process, were trusted - my idea (like the proposed syscall) would be for the plugins to tame themselves, knowing what privileges they would need to work, and dropping everything else, so that they couldn't be used as an exploit. It wasn't to protect the system from the plugin authors themselves.
Post reply on HN