Priv Sep SSH has / as CWD

[Damien Miller]

On Sun, 14 Feb 2010, Jon Kibler wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi,
> 
> Thanks for your reply.
> 
> Looking at the man pages for sshd and sshd_config, it is not 100% clear
> that when privilege separation occurs that the daemon is chrooted to
> /var/empty (or elsewhere). However, that makes sense. Thanks for the
> clarification. It would be good if that information got included in the
> man pages.

I don't think the manual pages need to detail the internal operations
of each program. People who are interested in privilege separation would
do better to read Niels' original paper at:

http://www.citi.umich.edu/u/provos/papers/privsep.pdf

> Regarding the sshd listener running in "/" and world readable core
> files... unfortunately, that is the way that RHEL/CentOS is configured.
> In the "functions" for init (/etc/init.d/functions), one of the first
> steps is to set 'umask 022'. I have tried to change this in the past
> only to have stuff break. I have also tried setting permissions on "/"
> to 751 and also broke stuff. Thus, for daemons that run with "/" as
> their home directory, we can get core files in "/" that are world
> readable. I do not like it, but that is the RHEL environment I have to
> live with. :-(

If RHEL drops core files from privileged processes that are world-readable
then the system has a major security vulnerability independent of sshd. 
Any system daemon that calls getpw* that can be tricked into segfaulting
would likely leak password hashes from /etc/shadow (or worse). Have you
confirmed that core files are indeed world-readable?

> This leaves me with 2 questions:
>    1) Can I change the init script for sshd to set umask to '077'
> without breaking stuff?

This shouldn't break anything in sshd.

>    2) If I put 'cd /var/run' in the init script before sshd starts, will
> it actually run from /var/run without breaking stuff?

No, it will always chroot to /. This is done automatically by the call to
daemon(3) and is perfectly normal practice for system daemons, probably
to allow administrators to be able to unmount filesystems without having
to kill processes.

-d