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.

16 comments

  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. If it aint broke... by b_pretender · · Score: 0, Troll

    ...then don't fix it!!

    1. 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.
  3. 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?

    1. Re:So how long until... by Anonymous Coward · · Score: 0

      Hopefully not too long...

    2. Re:So how long until... by Anonymous Coward · · Score: 0

      Um, hold on there. Some of us using UNIXes derived from older sources are limited to a few thousand local users. What if we want to have qmail, djbdns, AND OpenSSH?

  4. The same strategy in a ftp daemon by smcv · · Score: 1

    This sounds a lot like twoftpd, which seems like a great idea.

  5. 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 software_non_olet · · Score: 1

      Hhhm, let me see wether I've understood you.

      You can have this functionality by giving the user a 'dummy-shell', which is only capable of spawning the sftp-server - perhaps chrooted or not (like ssh.com does it), right? Then the decision wether a full shell is given or just sftp-access is based on the user's shell entry in /etc/passwd. Simple, starightforward and full in tune with the system as it is designed to be.

      What do you want to gain from making this decision in the ssh-daemon? You would then have two sshd's running, each on a separate port, but you would still need to define which user is allowed to use which daemon.

      So the only thing you 'gain' is the absense of all this channel-overhead (with it's potential bugs), but the price would be to have to maintain two daemons which share a lot of common coding.

      I think your proposal would induce more work to be done and is more error-prone because of two daemons to maintain.

      To 'filter' out the sftp-server functionality with a simple dummy-shell looks much more secure and is at the same time much less work than to cut ssh into two (or three, or four...) pieces.

    2. 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?

    3. Re:what would be cool... by software_non_olet · · Score: 1

      Aah, Now I understand you (perhaps) better.
      Your aim is (at least to include) anonymous sftp access.

      Yes, you are right, for that purpose a separate sftp-only ssh is best. That is, if you think that neccessary. Could be an alternative to anon ftp with the added security that a man-in-the-middle could not fumble with the files down- or up-loaded.

      But then this is no longer ssh. Such a thing should have it's separate port and individual PAM-file etc. Otherwise you end up where ssh is now - a main ssh authentication process plus a sftp subsystem channel.

      Yet overall I think such an approach is too much work compared with the current situation, where sftp is a channel - double updates of similar code etc. The two pieces of code are bound to differ sooner or later.

      ssh is in such a wide-spread and security-sensitive use, that patches are bound to be done fast. While your sftp-only ssh might only get second priority.

      So overall for authenticated sfpt-access I would prefer to use the standard ssh, after all. And for anonymous (urgh!) access ftp is doing it's job pretty well - especially within a chroot jail or on a separate machine.

      Niels Provos' proposal meant to create abstraction layers with different privileges and with practically no common code (a horizontally split of ssh so to say), while your idea creates a vertical split with much code-copying (or #ifdefs or common libraries, which then again spoil your security-objective etc).

      Finally it runs down to a matter of 'taste' or 'feeling', I think. My feeling is it, better not to do it. The existing subsystem seperation is allready doing it's job in that area.

      Better trust anonymous shh-sftp than anonymous ftp or a totally new piece of software .o)

      Greetings

    4. 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.

    5. Re:what would be cool... by software_non_olet · · Score: 1

      Yes, Polo,

      I see your point and the added security and separate administration possibilties may be worth the additional development and maintenance costs IMO. E.g. using separate firewall rules and different means of authentication is appealing.

      And then such a (say) sftp-deamon should have it's separate port and PAM-entry. While using the same protocol (with functionality of limiting everything to file-access only), so that existing sftp-clients can be used without software changes - just entering a different port number.

      The idea looks interesting enough to discuss it in the openssh development list and try to set up a prototype implementation.

      I don't have the time for that, but I'll donate my birthday (the 26th) as port number for the project. .o)

  6. Microsoft .NET by Anonymous Coward · · Score: 0

    This sounds a bit like the trusted and untrusted code thing in Microsoft's .NET, only more hassle because you have to go to the trouble of creating actual users for different security contexts, rather than it being done automatically.