Subject: Re: chroot(2)
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
From: Simon J. Gerraty <email@example.com>
Date: 10/02/1998 11:57:37
der Mouse writes:
>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
>easy to leverage privilege. It would also make escaping from a chroot
By using r* back to the same box after gaining another user's id?
or did you have something else in mind?
>To address the first, I would suggest that processes, as well as mount
>points, have a "don't honor set-id bits" flag, and that non-root
>chroot() should set this flag. To address the second, I suggest
>requiring that the path passed to chroot be an absolute path (in
>particular, "." is disallowed).
Marcus Ranum once described described using the simple fact that
chroot had been done to prevent all sorts of system calls
working. It was specific to making it impossible for a
chrooted process used for a firewall proxy to escape...
Your idea above sounds like a more general application of the
same idea - could be very handy. I hate having to start
proxies as root _just_ so they can chroot(2). Of course I don't
have source to all the OS's I build firewalls on :-)