From owner-freebsd-security Mon Apr 9 11: 8:39 2001 Delivered-To: freebsd-security@freebsd.org Received: from office.admaster.pl (office.admaster.pl [212.160.251.44]) by hub.freebsd.org (Postfix) with ESMTP id 7955D37B422 for ; Mon, 9 Apr 2001 11:08:28 -0700 (PDT) (envelope-from s.zak@admaster.pl) Received: by office.admaster.pl (Postfix, from userid 1001) id 55C6985B13; Mon, 9 Apr 2001 20:08:17 +0200 (CEST) From: Slawek Zak To: freebsd-security@freebsd.org Subject: [Luke Mewburn ] LD_CHROOT idea Date: 09 Apr 2001 20:08:17 +0200 Message-ID: <867l0uhrou.fsf@office.admaster.pl> Lines: 53 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.1 (GTK) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I post it in case you don't follow the NetBSD security list... What do you think about the following idea? It would greatly simplify building chrooted environments but are there any negative implications? --------------------[ Forwarded message ]----------------------------- Date: Fri, 6 Apr 2001 15:57:07 +1000 From: Luke Mewburn To: tech-security@netbsd.org Subject: LD_CHROOT idea 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. ---------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message