Hi folks
The commit 778c1144771f0064b6f51bee865cceb0d996f2f9 replaced the old
root-based security checks in procfs with processed based ones.
This makes the old check for chroot "[ -r /proc/1/root ]" unusable as
readlink on it now always succedds. Also it provides buggy values inside
a chroot, both /proc/1/root and /proc/self/root points to / but in real
they are different.
Is this a desired output or can I call this a bug? If the behaviour is
correct, is there a replacement for this check?
Bastian
--
Behind every great man, there is a woman -- urging him on.
-- Harry Mudd, "I, Mudd", stardate 4513.3
Bastian Blank <[email protected]> writes:
> Is this a desired output or can I call this a bug? If the behaviour is
> correct, is there a replacement for this check?
[ "$(stat -c "%d/%i" /)" = "$(stat -Lc "%d/%i" /proc/1/root)" ]
Andreas.
--
Andreas Schwab, SuSE Labs, [email protected]
SuSE Linux Products GmbH, Maxfeldstra?e 5, 90409 N?rnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
On Thu, Oct 12, 2006 at 04:02:24PM +0200, Bastian Blank wrote:
> The commit 778c1144771f0064b6f51bee865cceb0d996f2f9 replaced the old
> root-based security checks in procfs with processed based ones.
The new behaviour even allows a user to escape from the chroot by using
chdir to /proc/$pid/cwd or /proc/$pid/root of a process he owns and
lives outside of the chroot.
Bastian
--
Punishment becomes ineffective after a certain point. Men become insensitive.
-- Eneg, "Patterns of Force", stardate 2534.7
Bastian Blank <[email protected]> writes:
> On Thu, Oct 12, 2006 at 04:02:24PM +0200, Bastian Blank wrote:
>> The commit 778c1144771f0064b6f51bee865cceb0d996f2f9 replaced the old
>> root-based security checks in procfs with processed based ones.
>
> The new behaviour even allows a user to escape from the chroot by using
> chdir to /proc/$pid/cwd or /proc/$pid/root of a process he owns and
> lives outside of the chroot.
Yep. It makes it obvious that you can do that.
If you were in a chroot you could always ptrace a process you own
that was outside of the chroot, and cause it to do things, such as
open a unix domain socket and pass you it's current root directory.
chroot by itself has never been much of a jail.
Eric
On Fri, Oct 13, 2006 at 09:02:50PM -0600, Eric W. Biederman wrote:
> Bastian Blank <[email protected]> writes:
>
> > On Thu, Oct 12, 2006 at 04:02:24PM +0200, Bastian Blank wrote:
> >> The commit 778c1144771f0064b6f51bee865cceb0d996f2f9 replaced the old
> >> root-based security checks in procfs with processed based ones.
> >
> > The new behaviour even allows a user to escape from the chroot by using
> > chdir to /proc/$pid/cwd or /proc/$pid/root of a process he owns and
> > lives outside of the chroot.
>
> Yep. It makes it obvious that you can do that.
>
> If you were in a chroot you could always ptrace a process you own
> that was outside of the chroot, and cause it to do things, such as
> open a unix domain socket and pass you it's current root directory.
yes, but it's a bit trickier than remotely telling a script to basically
do chdir("/proc/1/cwd").
> chroot by itself has never been much of a jail.
OK, but that's not a reason for breaking trivial protection against
trivial escape methods.
Also, people sometimes compose build environments using chroot, which
at least protect them from accidental escape and corruption of the root
FS. It is a bit scary to know that a poorly designed install script
could break out of the chroot by abusing /proc or simply doing dirty
things such as "find / -follow" for any valid purpose under such an
environment.
Chroot is a useful tool for build and test environments, it's dangerous
to break it that way.
I'd clearly prefer that tasks outside the chroot show broken links
for cwd, root and exe under /proc.
Regards,
willy