/.
I hope I haven't crossed the line between determined and annoying. I
thought we were done, but now I find meat still on this bone.
Posit a normal process having some filesystem root, and a current
working directory (pwd) lying within that root subtree. When chroot is
performed, pwd is l
On Wed, 26 Sep 2007, Miloslav Semler wrote:
> so there is no discussion about mount & others. I think, if you have
> CAP_SYS_MOUNT/CAP_SYS_ADMIN, you need not solve chroot() and how to
> break it.
CAP_SYS_PTRACE allows you to break out of chroot in a pretty trivial way
too.
--
Jiri Kosina
-
On Wed, 26 Sep 2007, David Newall wrote:
> Miloslav Semler pointed out that a root process can chdir("..") out of
> its chroot. Although this is documented in the man page, it conflicts
> with the essential function, which is to change the root directory of
> the process.
The root directory,
On Wed, Sep 26, 2007 at 08:43:44PM +0930, David Newall wrote:
> Olivier Galibert wrote:
> >chroot does not allow you to walk out if you're in.
>
> You're mistaken. Or more properly, further use of chroot lets you walk
> out. This really has been said before, and before, and before.
>
>chro
This is basically both painfully racy and easily broken with umount
and/or access to proc. See this busybox-compatible example:
## Set up chroot
mkdir /root1
mount -o mode=0750 -t tmpfs tmpfs /root1
cp -a /bin/busybox /root1/busybox
## Enter chroot
chroot /root1 /busybox
## Mount proc
/bu
Al Viro napsal(a):
On Wed, Sep 26, 2007 at 03:11:33PM +0200, Miloslav Semler wrote:
As for the nested-chroot() bit, the root user inside of a chroot is
always allowed to chroot(). This is necessary for test-suites for
various distro installers, chroot once to enter the installer playpen,
i
On Wed, 26 Sep 2007 13:34:53 +0200
Miloslav Semler <[EMAIL PROTECTED]> wrote:
> Alan Cox napsal(a):
> >> but many program use this as security feature. So do you think that bind
> >> may use vserver?
> >>
> >
> > It would be a lot stronger if it did. A bind running non-root will be
> > proba
On Sep 26, 2007, at 09:11:33, Miloslav Semler wrote:
+ long directory_is_out(struct vfsmount *wdmnt, struct dentry
*wdentry,
+ struct vfsmount *rootmnt, struct dentry *root)
+ {
+ struct nameidata oldentry, newentry;
+ long ret = 1;
+
+ read_lock(¤t->fs-
On Wed, Sep 26, 2007 at 03:11:33PM +0200, Miloslav Semler wrote:
> >As for the nested-chroot() bit, the root user inside of a chroot is
> >always allowed to chroot(). This is necessary for test-suites for
> >various distro installers, chroot once to enter the installer playpen,
> >installer chr
On Wed, 26 Sep 2007, David Newall wrote:
> Olivier Galibert wrote:
>> chroot does not allow you to walk out if you're in.
>
> You're mistaken. Or more properly, further use of chroot lets you walk
> out. This really has been said before, and before, and before.
>
>chroot("subtree"); // en
On Wednesday 26 September 2007 13:06:51 David Newall wrote:
> Alan Cox wrote:
> >>> The dot-dot entry in the root directory is interpreted to mean the
> >>> root directory itself. Thus, dot-dot cannot be used to access files
> >>> outside the subtree rooted at the root directory.
> >
> > Which is b
Kyle Moffett napsal(a):
On Sep 26, 2007, at 06:27:38, David Newall wrote:
Kyle Moffett wrote:
David, please do tell myself and Adrian how "locking down" chroot()
the way you want will avoid letting root break out through any of
the above ways?
As has been said, there are thousands of ways to
On Sep 26, 2007, at 06:27:38, David Newall wrote:
Kyle Moffett wrote:
David, please do tell myself and Adrian how "locking down" chroot
() the way you want will avoid letting root break out through any
of the above ways?
As has been said, there are thousands of ways to break out of a
chroo
Alan Cox napsal(a):
but many program use this as security feature. So do you think that bind
may use vserver?
It would be a lot stronger if it did. A bind running non-root will be
probably safe. A bind running as root can be attacked and break out of a
chroot trivially. I guess it depends
> >>> The dot-dot entry in the root directory is interpreted to mean the
> >>> root directory itself. Thus, dot-dot cannot be used to access files
> >>> outside the subtree rooted at the root directory.
> >>>
> >
> > Which is behaviour chroot preserves properly.
> >
> And yet it is the
Olivier Galibert wrote:
chroot does not allow you to walk out if you're in.
You're mistaken. Or more properly, further use of chroot lets you walk
out. This really has been said before, and before, and before.
chroot("subtree"); // enter chroot
chdir("/");// now at subtree
c
Alan Cox wrote:
The dot-dot entry in the root directory is interpreted to mean the
root directory itself. Thus, dot-dot cannot be used to access files
outside the subtree rooted at the root directory.
Which is behaviour chroot preserves properly.
And yet it is the dot-dot entry whi
On Wed, Sep 26, 2007 at 07:57:38PM +0930, David Newall wrote:
> As has been said, there are thousands of ways to break out of a chroot.
> It's just that one of them should not be that chroot lets you walk out.
chroot does not allow you to walk out if you're in. It only allows
you to walk outs
> > The dot-dot entry in the root directory is interpreted to mean the
> > root directory itself. Thus, dot-dot cannot be used to access files
> > outside the subtree rooted at the root directory.
Which is behaviour chroot preserves properly.
The specification says explicitly
"The proc
Kyle Moffett wrote:
David, please do tell myself and Adrian how "locking down" chroot()
the way you want will avoid letting root break out through any of the
above ways?
As has been said, there are thousands of ways to break out of a chroot.
It's just that one of them should not be that chro
Alan Cox wrote:
Good call. Though I suppose, since it's used 24x7 to aid security on
countless production servers, that security dwarfs testing. Still,
debugging, yes that's valid.
I don't suppose it makes and difference; whatever the purpose, a chroot
that doesn't change the root is buggy.
On Wed, Sep 26, 2007 at 01:21:08AM -0400, Kyle Moffett wrote:
(...)
> Now, like magic, the entire system is once more accessible.
>
> Alternatively you could:
> mount -t proc proc /proc
> cat /proc/1/mounts
> mount -t $ROOTFS_FROM_PROC $ROOTDEV_FROM_PROC /
Since 2.6.20, it was even simpler
On Sep 25, 2007, at 20:55:51, Adrian Bunk wrote:
On Wed, Sep 26, 2007 at 09:20:54AM +0930, David Newall wrote:
Good call. Though I suppose, since it's used 24x7 to aid security
on countless production servers, that security dwarfs testing.
Still, debugging, yes that's valid.
Incompetent p
On Wed, Sep 26, 2007 at 09:20:54AM +0930, David Newall wrote:
> Alan Cox wrote:
>> On Wed, 26 Sep 2007 01:05:07 +0930
>> David Newall <[EMAIL PROTECTED]> wrote:
>>> Alan Cox wrote:
>>>
> Marek's loading dynamic libraries, it seems clear that the prime
> purpose of chroot is to aid sec
> Good call. Though I suppose, since it's used 24x7 to aid security on
> countless production servers, that security dwarfs testing. Still,
> debugging, yes that's valid.
>
> I don't suppose it makes and difference; whatever the purpose, a chroot
> that doesn't change the root is buggy.
It d
Alan Cox wrote:
On Wed, 26 Sep 2007 01:05:07 +0930
David Newall <[EMAIL PROTECTED]> wrote:
Alan Cox wrote:
Marek's loading dynamic libraries, it seems clear that the prime purpose
of chroot is to aid security. Being able to cd your way out is handy
Does it - I can't find a
Jan Engelhardt wrote:
On Sep 26 2007 01:11, David Newall wrote:
Jan Engelhardt wrote:
On Sep 26 2007 00:40, David Newall wrote:
Miloslav Semler pointed out that a root process can chdir("..") out of its
chroot.
So what? Just do this: chdir into the root after chroot
On Tue, Sep 25, 2007 at 07:05:06PM +0200, Jan Engelhardt wrote:
Perhaps that was formulated a bit sloppy. It of course means
"On chroot(2), implicitly close all FDs that point outside."
Bollocks. Pack 'em into SCM_RIGHTS datagram, send to yourself,
do chroot, recvmsg() and move on,
Jan Engelhardt napsal(a):
On Sep 25 2007 19:00, Miloslav Semler wrote:
This does not help. Let's try:
chroot somewhere
mkdir foo
fd = open /
chroot foo
('fd' implicitly closed and chdir to /foo)
Really? Try it. I am sure, that this works. You can create directory i
On Tue, Sep 25, 2007 at 07:05:06PM +0200, Jan Engelhardt wrote:
> Perhaps that was formulated a bit sloppy. It of course means
> "On chroot(2), implicitly close all FDs that point outside."
Bollocks. Pack 'em into SCM_RIGHTS datagram, send to yourself,
do chroot, recvmsg() and move on, cheerfull
On Sep 25 2007 19:00, Miloslav Semler wrote:
>> > This does not help. Let's try:
>> > chroot somewhere
>> > mkdir foo
>> > fd = open /
>> > chroot foo
>> >
>>
>> ('fd' implicitly closed and chdir to /foo)
>>
> Really? Try it. I am sure, that this works. You can create directory in chroot
This does not help. Let's try:
chroot somewhere
mkdir foo
fd = open /
chroot foo
('fd' implicitly closed and chdir to /foo)
Really? Try it. I am sure, that this works. You can create directory in
chroot and break chroot by this. fd is not closed, because linux doesn't
close descrip
Quoting Miloslav Semler ([EMAIL PROTECTED]):
>
So what? Just do this: chdir into the root after chroot.
>>> I don't think so. His exploit just got me all the way out of a chroot
>>> within a
>>> chroot within a chroot, inclusive of lots of chdirs.
>>>
>>
>> Close all fds tha
On Sep 25 2007 18:19, Miloslav Semler wrote:
>> > > So what? Just do this: chdir into the root after chroot.
>> > >
>> > I don't think so. His exploit just got me all the way out of a chroot
>> > within a
>> > chroot within a chroot, inclusive of lots of chdirs.
>> >
>>
>> Close all f
On Wed, 26 Sep 2007 01:05:07 +0930
David Newall <[EMAIL PROTECTED]> wrote:
> Alan Cox wrote:
> >> Marek's loading dynamic libraries, it seems clear that the prime
> >> purpose of chroot is to aid security. Being able to cd your way
> >> out is handy
> >
> > Does it - I can't find any evidence fo
So what? Just do this: chdir into the root after chroot.
I don't think so. His exploit just got me all the way out of a chroot within a
chroot within a chroot, inclusive of lots of chdirs.
Close all fds that point to directories outside the root ;-)
This does not help. Let
On Tue, Sep 25, 2007 at 05:43:58PM +0200, Miloslav Semler wrote:
> Adrian Bunk napsal(a):
>> On Wed, Sep 26, 2007 at 12:40:27AM +0930, David Newall wrote:
>>
>>
>>> Miloslav Semler pointed out that a root process can chdir("..") out of
>>> its chroot. Although this is documented in the man pag
Adrian Bunk napsal(a):
On Wed, Sep 26, 2007 at 12:40:27AM +0930, David Newall wrote:
Miloslav Semler pointed out that a root process can chdir("..") out of its
chroot. Although this is documented in the man page, it conflicts with the
essential function, which is to change the root directo
On Sep 26 2007 01:11, David Newall wrote:
> Jan Engelhardt wrote:
>> On Sep 26 2007 00:40, David Newall wrote:
>>
>> > Miloslav Semler pointed out that a root process can chdir("..") out of its
>> > chroot.
>> So what? Just do this: chdir into the root after chroot.
>
> I don't think so. His e
On Sep 25 2007 16:48, Alan Cox wrote:
>David Newall <[EMAIL PROTECTED]> wrote:
>> Alan Cox wrote:
Marek's loading dynamic libraries, it seems clear that the prime
purpose of chroot is to aid security. Being able to cd your way
out is handy
>>>
>>> Does it - I can't find any ev
On Sep 26 2007 00:40, David Newall wrote:
Miloslav Semler pointed out that a root process can chdir("..") out of its
chroot. Although this is documented in the man page, it conflicts with the
essential function, which is to change the root directory of the process. In
addition to any creat
On Wed, 26 Sep 2007 01:05:07 +0930
David Newall <[EMAIL PROTECTED]> wrote:
> Alan Cox wrote:
> >> Marek's loading dynamic libraries, it seems clear that the prime purpose
> >> of chroot is to aid security. Being able to cd your way out is handy
> >>
> >
> > Does it - I can't find any evide
Jan Engelhardt wrote:
On Sep 26 2007 00:40, David Newall wrote:
Miloslav Semler pointed out that a root process can chdir("..") out of its
chroot.
So what? Just do this: chdir into the root after chroot.
I don't think so. His exploit just got me all the way out of a chroot
within a ch
Alan Cox wrote:
Marek's loading dynamic libraries, it seems clear that the prime purpose
of chroot is to aid security. Being able to cd your way out is handy
Does it - I can't find any evidence for that.
It seems self-evident to me. What do you think is it prime purpose?
A root use
On Wed, Sep 26, 2007 at 12:40:27AM +0930, David Newall wrote:
> Miloslav Semler pointed out that a root process can chdir("..") out of its
> chroot. Although this is documented in the man page, it conflicts with the
> essential function, which is to change the root directory of the process.
>
> Marek's loading dynamic libraries, it seems clear that the prime purpose
> of chroot is to aid security. Being able to cd your way out is handy
Does it - I can't find any evidence for that. I think you are confusing
containers and chroot. They are quite different things. A root user can
get o
On Sep 26 2007 00:40, David Newall wrote:
>
> Miloslav Semler pointed out that a root process can chdir("..") out of its
> chroot. Although this is documented in the man page, it conflicts with the
> essential function, which is to change the root directory of the process. In
> addition to any c
Miloslav Semler pointed out that a root process can chdir("..") out of
its chroot. Although this is documented in the man page, it conflicts
with the essential function, which is to change the root directory of
the process. In addition to any creative uses, for example Philipp
Marek's loading
48 matches
Mail list logo
