[bind10-dev] should the socket creator use chdir?

[Shane Kerr]

Michal,

On Mon, 2011-12-05 at 22:13 +0100, Michal 'vorner' Vaner wrote:
> On Mon, Dec 05, 2011 at 10:31:22AM -0800, JINMEI Tatuya / 神明達哉 wrote:
> > The socket creator process will be the only one that needs to keep the
> > root privilege.  I wonder whether we should at least allow it to run
> > under a 'chroot' environment for best possible security (I know it's
> > not even expected to directly communicate with other BIND 10 processes
> > than the boss process, let alone arbitrary remote client nodes, but
> > when it comes to security paranoia is often better than optimism).
> > Since it's intended to be a simple stand-alone program that could even
> > be statically linked, it should be easy to realize that.
> 
> I think it is worth it. Actually, if it did the chdir call itself, it wouldn't
> need to be statically linked. It would start up, including all the needed
> libraries, then make a temporary directory somewhere, chroot there and possibly
> delete the directory.

Hm... removing the directory might be useful, at least sometimes. On my
Linux desktop:

-------------------------------------------------------------------------
    TERMINAL 1			    TERMINAL 2
$ mkdir /tmp/foo
$ cd /tmp/foo
				$ rmdir /tmp/foo
$ cd ..
$ pwd
/tmp
-------------------------------------------------------------------------

So, a simple mkdir()/chdir()/rmdir() does not help. However:

-------------------------------------------------------------------------
    TERMINAL 1			    TERMINAL 2
$ mkdir -p /tmp/foo/bar
$ cd /tmp/foo/bar
				$ rmdir /tmp/foo/bar
				$ rmdir /tmp/foo
$ cd ..
cd: error retrieving current directory: getcwd: cannot access parent
directories: No such file or directory
-------------------------------------------------------------------------

When I then check the status of the process using lsof I find:

COMMAND  PID  USER   FD   TYPE DEVICE  SIZE/OFF   NODE NAME
bash    9952 shane  cwd    DIR    8,2         0 115460 /tmp/foo (deleted)

So this might offer some isolation.

> However, it's more a publicity thing than security thing. A root user is able to
> leave chrooted environment, at last in linux. The kernel developers refuse to
> „fix“ it, as they say it is a feature, not a bug and that chroot is not security
> related anyway.

Yup, although as you note:

> Anyway, I'd like to make it work first. Then we can add few more security
> things, like the chroot or possibility to drop root privileges and preserve only
> the one for binding sockets (if it's possible). But I'd still fear we should do
> most of the security checks and worrying on processes that communicate over the
> network, like auth or resolver.

If you can drop privileges then the chroot() jail is much, much tougher
to break out of (Linux offers the withdrawn POSIX proposed standards on
capabilities, which support this, Google "linux capabilites" to read
more). FreeBSD might be able to use jail() for this, although I'm not
sure about the behavior when new interfaces come online. Solaris also
apparently has some sort of RBAC which might be useful, although again
I'm not sure.

I agree this isn't the most likely vulnerability, but if this is indeed
the only component running as root then it is probably a good idea to
take extra care. :)

--
Shane