On Fri, Jun 23, 2006 at 12:00:17PM +1200, Joshua Sandbrook wrote:
> On Thursday 22 June 2006 22:26, Joachim Schipper wrote:
> > A quick grep through /usr/src/usr.bin/ssh suggests that ssh (and, most
> > likely, sftp) interacts with /dev/null quite a bit. It might be possible
> > to change the code to work without, but that would take quite a bit of
> > work I fear.
> >
> > An alternative hack would be to change sftp directly; in this case, it
> > can safely open /dev/null and then call chroot() at the appropriate
> > time. OTOH, you have a custom patch that you should apply at the
> > appropriate time and place, which, too, has its disadvantages.
> >
> > Also, be *very* careful in writing the shell, as it must be suid root
> > for what you want it to do... this, in fact, suggests that the best
> > solution might be to write a trivial shell and just have
> > /home/*/dev/null. Or, for that matter, /home/dev/null and chroot into
> > /home.
>
> Thanks for the reply...
>
> It is sftp-server that tries to open /dev/null.
>
> As I dont want to modify sftp-server or anything like that, I think im going
> to just populate each chroot environment with a /dev/null. However, as I dont
> want /home to have any devices on it, is there a way to have some sort of
> file type that simply throws the data away like /dev/null does?
You could set up a named pipe (mkfifo(1)), and have a process
continually drain it (cat /home/john/dev/null >/dev/null &); however,
while this would work for the most likely use (writing to /dev/null), it
wouldn't allow for reading.
I'm not sure if sftp-server ever reads from /dev/null, but it is not
impossible. Strange errors will occur if this is the case.
> As for the shell, Yep, I am being carefull with it.. all the shell actaully
> does, is checks if the arguments given to it is
> '-c /usr/libexec/sftp-server', and if it is, it then chroots to the users
> home dir, and then it sets effective uid to the uid that called the shell,
> and then it executes /usr/libexec/sftp-server. Not much code at all.
>
> I want to research more into possible security hassles ( like
> /home/foo/.ssh ) and stuff like that later on. Any suggestions in this
> area? ( security )
Yes, make sure you also set real uid. A small part of
/usr/src/usr.sbin/tcpdump/privsep.c:
/* Child - drop suid privileges */
gid = getgid();
uid = getuid();
if (setresgid(gid, gid, gid) == -1)
err(1, "setresgid() failed");
if (setresuid(uid, uid, uid) == -1)
err(1, "setresuid() failed");
Do note that this is only necessary if the shell is suid and/or sgid;
however, normal users don't have the rights to call chroot(2), so these
additional priviliges are necessary.
Also, you are aware that you perform chroot(), setresuid() and
setresgid(), and only then execve()? This means that you'll need some
binaries in the home directories...
So, be aware that deleting a file or directory requires write priviliges
on the parent directory; i.e., john can replace
/home/john/bin/sftp-server by an arbitrary binary if john has write
priviliges on his home directory, hence my suggestion to use /home
(which is typically only writable by root) above.
(An alternate solution is to make /home/john owned by root, group john,
and with priviliges 0750; this would break too many things to be
feasible if shells are allowed, but just might work if only considering
sftp.)
Finally, be aware of the many other options sshd allows, like various
ways of tunneling. For the same reason as above, those cannot be
disabled in /home/john/.ssh/authorized_keys only (disabling them there
works iff the user cannot mess with this file, which is clearly not the
case if the user has access to sftp). Either disable them sshd-wide or
set AuthorizedKeysFile (see sshd_config(5)) to something like
/home/.keys/%u/authorized_keys.
Note that running any number of ssh daemons in parallel works just fine,
subject to some caveats (they can, of course, not listen on the same
ports on the same interfaces; they are quite CPU intensive; and random
number quality may degrade if the pool is drained sufficiently fast).
Joachim
