Hacker News Reader

Comment by wfunction | Hacker News Reader

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.

View on HN

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.

think more like emacs or vim. plugins can add any number of things that isnt just file read/write. they can add new syscalls for a built in debugger (ptrace, strace, etc.) or even add an opengl layer for coding in 3d.

That's basically what I meant, thanks for explaining it clearly.

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.

I don't think that the plugin should declare it's behavior. Consider the case were you have a shared webserver and a php-plugin for one user (say a wordpress installation). Then the user ( or anyone with write access to the user directory) can control the permissions of the server.

On the other hand, a well designed plugin interface could set default permissions. For example the plugin interface could have a SQL method, so that a plugin does not need to talk to a socket directly.

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)

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.

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.

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.

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

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.

the flags will need to be configurable through config file (e.g nginx, apache). When you explicitly grant more access because of a plugin, you know what you are getting into.

But assume nginx supports tame now, you know at least what the process can do and what it cannot do explicitly. If one day a zero-day attack was discovered in nginx, nginx running tame will have a lesser security impact, at least in theory.

Reply on news.ycombinator.com