5 ms·

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 plug

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.

icebraining 11y ago
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.
obstinate 11y ago
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.
- yk 11y ago
  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.
wmf 11y ago
I think the OpenBSD philosophy is to run plugins in separate processes.
- paulannesley 11y ago
  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.
  - icebraining 11y ago
    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.
    - eloff 11y ago
      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.
      - wbl 11y ago
        Privileges should be inherited across fork and monotonic down to solve this problem.
      - asveikau 11y ago
        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.
        eloff 11y ago
        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.
        asveikau 11y ago
        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.
        icebraining 11y ago
        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.
MBCook 11y ago
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.
- simcop2387 11y ago
  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.
  - wfunction 11y ago
    That's basically what I meant, thanks for explaining it clearly.
halayli 11y ago
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.
SFjulie1 11y ago
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)

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.

icebraining 11y ago

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.

obstinate 11y ago

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.

yk 11y ago
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.

wmf 11y ago

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

paulannesley 11y ago
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.
- icebraining 11y ago
  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.
  - eloff 11y ago
    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.
    - wbl 11y ago
      Privileges should be inherited across fork and monotonic down to solve this problem.
    - asveikau 11y ago
      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.
      - eloff 11y ago
        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.
        asveikau 11y ago
        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.
        icebraining 11y ago
        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.

MBCook 11y ago

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.

simcop2387 11y ago
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.
- wfunction 11y ago
  That's basically what I meant, thanks for explaining it clearly.

halayli 11y ago

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.

SFjulie1 11y ago

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)