Slashdot Mirror

← Back to Stories (view on slashdot.org)

Separating OpenSSH's Privileges For Safety

Posted by timothy on from the making-a-list-checking-it-twice dept.

Niels Provos writes: "Even though I should be working on my disseration proposal right now, I got side tracked with a little project. Markus and I have been working on a 'Privilege Separated OpenSSH.' The basic idea is that OpenSSH starts two processes, one privileged and one unprivileged. The unprivileged process deals with all the network data processing, while the privileged process monitors and decides if authentication was successful. This reduces the impact that bugs in for example third party libraries can have on OpenSSH. We hope that any privilege escalation will not be possible any more in the future." This privilege separation should show up in future versions of OpenSSH, including the portable version.

7 of 16 comments (clear)

  1. Good idea by melquiades · · Score: 2

    Since all is silent here, I'll post a word of encouragement:

    This is a fine idea. Separation of roles is good both for keeping code tidy and for security. Carry on!

    1. Re:Good idea by 4of12 · · Score: 2

      I'll second that.

      Anything to reduce the possibility of a security breach sounds good to me.

      Of course, the amount of work you have to do to implement this is a consideration and, hopefully, the resulting code is reasonably modular and understandable after everything is done?

      In some ways it sounds like the ideas of web security, where folks have tried to make httpd run as underprivileged as possible and separating it from other things, such as database activity.

      The chopping up of privileges between parts also seems reminescent of SEL, too.

      --
      "Provided by the management for your protection."
  2. So how long until... by Pathwalker · · Score: 2

    OpenSSH ends up looking like Qmail with each discrete task running as a separate program under a different user?

  3. Re:If it aint broke... by QuantumG · · Score: 2

    it is broke, that's the point.

    --
    How we know is more important than what we know.
  4. what would be cool... by Polo · · Score: 3, Interesting

    I tink it would be cool to have a version of sshd that would ONLY allow secure file transfer.

    I've done some porting work with ssh 2 and the protocol supports several types of "channels". Many of them deal with login and remote execution: "shell", "pty-req" and "exec".

    However, when you run scp or sftp (included with ssh2), the daemon uses ssh to invokes a "subsystem" channel request, with the subsystem of "sftp". (At least with versionn2 of the protocol, I don't think this happens with ssh version 1). This usually starts a daemon sub-process /usr/local/bin/sftp-server and channels all the session stuff to it.

    It would be cool if this was the only function available, and that the sftp directory was chosen on the fly per-user and chroot'd or something so that only a subset of files was available somehow. This would allow you to have a bunch of secure directories for your friends, or even anonymous sftp, without having to let people log into your machine.

    1. Re:what would be cool... by Polo · · Score: 2

      I don't think the 'dummy-shell' philosophy guarantees security.

      The openssh version mentioned in this article has two daemons for increased security. If they're dealing with the extra complexity of two daemons for increased security, is a file-access-only or read-only file-access sshd a far-fetched idea?

      How would you give someone limited access to your server for file-copy purposes with the current ssh? Are you *sure* they won't be able to write to their /etc/passwd entry or some shared library and gain full ssh shell access? What if there's a buffer overflow found in a couple of months?

      Would you trust it to anonymous-ssh?

    2. Re:what would be cool... by Polo · · Score: 2

      Hmmm... I think the main point is that file access (scp, which uses the 'sftp' channel) and execution access (ssh, which uses the 'shell', 'pty-req' and 'exec' channels) are inextricably linked in sshd.

      I think in some cases it would benefit from a clear separation, like the separation these guys have given sshd. The separation I would personally like is to allow certain people access to certain files WITHOUT giving them the ability
      to log in or access *all* files.

      Possibly, people without login privs could invoke a different daemon than the sftp-server daemon which already exists, and that would be possible within the current sshd framework. It would perform most of the file-access functions of sftp-server with chroot and/or read-only access.

      The sftp-server daemon is already a separate executable invoked by sshd. It translates raw file-access primitives that the remote ssh sends to file-system calls.

      Let's say you wanted to give some people access to your contact list. Or you wanted some customers to be able to access beta versions of your application, but you didn't want their password to be in clear-text. Or if you want some people to be able to access their webserver html directories or logs, without interfering with each other. The current ssh doesn't allow that, and ftp isn't secure.

      To be honest, I wasn't that interested in anonymous access, although if that was implemented, it would be a pretty good peer-to-peer setup.