Limiting the privileges of the service user on an SSH backup source machine

[mcdonc]

Hi Jim and folks,

This is not a bug report, it's more of an FYI about some research I did about trying to limit the commands executable by the service user of a syncoid SSH backup source machine. It's implemented on NixOS, but it's generalizable to any-UNIX.

The writeup is here:

https://github.com/mcdonc/.nixconfig/blob/master/videos/restricteduser/script.rst

There is an accompanying video:

https://www.youtube.com/watch?v=Zm_gn9UlyVg&t=629s

(a number of other videos about Syncoid and Sanoid preceded this one; they are referenced in the links above).

1. I'd be glad to hear whether this approach seems reasonable or it's terrible.
2. If it isn't terrible, I would be happy to do a writeup in the wiki about it.

Thanks!

[jimsalterjrs]

I love the enthusiasm, but I don't think you're really improving security much unfortunately. :'(

As you note in your gist, if any of the utilities rbash permits can write to disk, then escape is trivial. Well, we certainly don't have to look any further than pv.

pv < /usr/sbin/apache2 > /home/hackedserviceacct

And there's your webserver.

For that matter, allowing the use of ssh also presents an easy escape: even if you can't scp @.:/opt/hackingtool ./ what you CAN do is ssh @. cat /opt/hackingtool > /home/hackedserviceacct/hackingtool.

If you want to improve on security above and beyond using unprivileged service accounts for send and receive (preferably separate, each of which has only the zfs-delegated permissions necessary), the next reasonable step probably is making certain that those accounts have absolutely no write privileges outside their own home directory and possibly /tmp. You can't lock a service account for Sanoid down quite that far, because it needs to write to its cache and lockfiles. But syncoid doesn't need to write to the filesystem anywhere, so its send and receive service accounts can be chmodded into a very tiny corner and still function!

[mcdonc]

Thanks for the response response, Jim!

I love the enthusiasm, but I don't think you're really improving security much unfortunately. :'( As you note in your gist, if any of the utilities rbash permits can write to disk, then escape is trivial. Well, we certainly don't have to look any further than pv. pv < /usr/sbin/apache2 > /home/hackedserviceacct And there's your webserver.

FWIW, rbash doesn't allow redirections, so neither "<" nor ">" would work there.

For that matter, allowing the use of ssh also presents an easy escape: even if you can't scp @.:/opt/hackingtool ./ what you CAN do is ssh @. cat /opt/hackingtool > /home/hackedserviceacct/hackingtool.

Not if cat isn't available, which it isn't in my setup, nor would that redirection work under rbash.

If you want to improve on security above and beyond using unprivileged service accounts for send and receive (preferably separate, each of which has only the zfs-delegated permissions necessary), the next reasonable step probably is making certain that those accounts have absolutely no write privileges outside their own home directory and possibly /tmp. You can't lock a service account for Sanoid down quite that far, because it needs to write to its cache and lockfiles. But syncoid doesn't need to write to the filesystem anywhere, so its send and receive service accounts can be chmodded into a very tiny corner and still function!

Indeed they can! I think I've restricted it about as much on the send side as possible without doing some SELinux misery. I don't need to worry about the receive side, as that is taken care of by the NixOS integration of syncoid and sanoid (which are great, BTW; for sanoid, for example, it creates and destroys an entire UNIX account every time it runs and dynamically allocates the right zfs permissions to that account, it's kind mindblowing).

Anyway, rbash is indeed pretty laughable but I think in the case of syncoid at least, it's also pretty reasonable.