4 ms·

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 proc

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.

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.