Hacker News Reader

Comment by wmf | Hacker News Reader

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.

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.

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.

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.

Reply on news.ycombinator.com