Subject: LD_CHROOT idea
To: None <tech-security@netbsd.org>
From: Luke Mewburn <lukem@wasabisystems.com>
List: tech-security
Date: 04/06/2001 15:57:07
Hi people.

Matt Green told me about a proposal that Julian Assange made a few
years ago, and the more I consider it, the more I think it might
be useful.

The idea is to add a few more environment variables to ld.so;
	LD_CHROOT	directory to chdir(2) then chroot(2) to
	LD_CHROOT_UID	uid to run as (optional)
	LD_CHROOT_GID	gid to run as (optional)
	LD_CHROOT_GIDS	comma separated list of secondary gids (optional)

If LD_CHROOT is set and the process isn't setuid or setgid, then
before the actual entry into the process, ld.so chroot(2)s to
$LD_CHROOT, sets up the secondary groups, gid, and uid (if requested).
All of the LD_CHROOT* variables are cleared from the environment,
even if they're not used.

The benefits of this approach is that you:

	* don't need to have the shared libraries inside the chroot jail,
	  which improves maintainability of N chroot jails.

	* don't need to have the binary inside the chroot jail,
	  which means it can't be modified if the binary is attacked

Of course, this assumes that the VM system protects shared library
pages mapped in read-only. And you still need to put your config
files and a syslog socket in the cage, but that's trivial to
maintain.

I've got a sample implementation of this and it seems to work as
expected.

Comments?

PS: I'll add support into the rc.d stuff to take advantage of this if
we go ahead, for run_rc_command to detect whether to use LD_CHROOT or
chroot(8) depending on options passed in and if the program is static
or dynamic.

-- 
Luke Mewburn  <lukem@wasabisystems.com>  http://www.wasabisystems.com
Luke Mewburn     <lukem@netbsd.org>      http://www.netbsd.org
Wasabi Systems - providing NetBSD sales, support and service.