Re: Chroot bug (was: sys_chroot+sys_fchdir Fix)
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, '/' is changed, and if the process is capable of using
chroot, it may change the root directory again. Works as defined.
> In addition to any creative uses, for example Philipp
> Marek's loading dynamic libraries, it seems clear that the prime purpose
> of chroot is to aid security.
As long as root has more than a safe subset of capabilities, root can escape
a chroot.
Besides that, fchdir on open-at-chroot fds does not decrease the security,
since the attacker needs help from the outside root, who is not restricted
by chroot.
I'm more concerned about abstract unix sockets, they could be used to
send a file descriptor to compromised daemons and extend exploits to
the outside of a chroot and across namespaces - at least I suspect it.
The whole f* family of syscalls would be affected. This can be cured by
e.g. not allowing to receive fds if the root+namespace do not match.
> Being able to cd your way out is handy
> for the bad guys, but the good guys don't need it; there are a thousand
> better, safer solutions.
The good guys don't cd out, they open the instalkler archive, chroot to the
new system root and extract it there. Then they chroot back using the saved
cwd.
> If there truly is a need to be able to pop in and out of a chroot, then
> the solution should be obvious, such as with real versus effective user
> and group ids. An important quality of a solution would be a way to fix
> that essential function: to set the root in such a way that you can no
> longer pop out. But that is a separate question.
As in jail()?
As far as I know, the new virtualisation features sneaking into the kernel
will allow implementing a jail, too, in a more secure way than any hacking
on chroot can give.
> The question: is chroot buggy? I'm pleased to turn to SCO for an
> independent definition for chroot, from which I get the following:
>
> http://osr600doc.sco.com/en/man/html.S/chroot.S.html:
> >
> > The *..* entry in the root directory is interpreted to mean the root
> > directory itself. Thus, *..* cannot be used to access files outside
> > the subtree rooted at the root directory.
> >
>
> I argue chroot is buggy. Miloslav's patch might not be the right
> solution, but he has the right idea (i.e. fix it.)
There are implementations of chroot which imply chdir(), and not having f*
functions, they can not _directly_ acces files outside the chroot. But as
long as they can e.g. mknod /dev/mem or strace, they can do anything.
So let's not put a fingerprint sensor on that chinese paper door.
--
You know you're in trouble when packet floods are competing to flood you.
-- grc.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Chroot bug (was: sys_chroot+sys_fchdir Fix)
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, '/' is changed, and if the process is capable of using chroot, it may change the root directory again. Works as defined. In addition to any creative uses, for example Philipp Marek's loading dynamic libraries, it seems clear that the prime purpose of chroot is to aid security. As long as root has more than a safe subset of capabilities, root can escape a chroot. Besides that, fchdir on open-at-chroot fds does not decrease the security, since the attacker needs help from the outside root, who is not restricted by chroot. I'm more concerned about abstract unix sockets, they could be used to send a file descriptor to compromised daemons and extend exploits to the outside of a chroot and across namespaces - at least I suspect it. The whole f* family of syscalls would be affected. This can be cured by e.g. not allowing to receive fds if the root+namespace do not match. Being able to cd your way out is handy for the bad guys, but the good guys don't need it; there are a thousand better, safer solutions. The good guys don't cd out, they open the instalkler archive, chroot to the new system root and extract it there. Then they chroot back using the saved cwd. If there truly is a need to be able to pop in and out of a chroot, then the solution should be obvious, such as with real versus effective user and group ids. An important quality of a solution would be a way to fix that essential function: to set the root in such a way that you can no longer pop out. But that is a separate question. As in jail()? As far as I know, the new virtualisation features sneaking into the kernel will allow implementing a jail, too, in a more secure way than any hacking on chroot can give. The question: is chroot buggy? I'm pleased to turn to SCO for an independent definition for chroot, from which I get the following: http://osr600doc.sco.com/en/man/html.S/chroot.S.html: The *..* entry in the root directory is interpreted to mean the root directory itself. Thus, *..* cannot be used to access files outside the subtree rooted at the root directory. I argue chroot is buggy. Miloslav's patch might not be the right solution, but he has the right idea (i.e. fix it.) There are implementations of chroot which imply chdir(), and not having f* functions, they can not _directly_ acces files outside the chroot. But as long as they can e.g. mknod /dev/mem or strace, they can do anything. So let's not put a fingerprint sensor on that chinese paper door. -- You know you're in trouble when packet floods are competing to flood you. -- grc.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Chroot bug (was: sys_chroot+sys_fchdir Fix)
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.
> In addition to any creative uses, for example Philipp 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 for the bad guys, but
> the good guys don't need it; there are a thousand better, safer solutions.
>...
The bad guys most likely also now other tricks to escape the chroot.
If you are root in the chroot you can e.g. mount the partition with the
root filesystem inside the chroot.
If a bad guy becomes root inside a chroot it's game over.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Chroot bug (was: sys_chroot+sys_fchdir Fix)
> 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 out of a chroot a million different ways Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Chroot bug (was: sys_chroot+sys_fchdir Fix)
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 creative uses, for example Philipp 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 for the bad guys, but the good guys
> don't need it; there are a thousand better, safer solutions.
So what? Just do this: chdir into the root after chroot.
It won't conform to SVR4/4.4BSD anymore, but hey, let Linux set some
sane standard ain't bad either. I doubt anyone really relies on the
fact that after chroot, your cwd might be outside the root.
Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]>
---
fs/open.c |1 +
1 file changed, 1 insertion(+)
Index: linux-2.6.23/fs/open.c
===
--- linux-2.6.23.orig/fs/open.c
+++ linux-2.6.23/fs/open.c
@@ -547,6 +547,7 @@ asmlinkage long sys_chroot(const char __
set_fs_root(current->fs, nd.mnt, nd.dentry);
set_fs_altroot();
+ set_fs_pwd(current->fs, nd.mnt, nd.dentry);
error = 0;
dput_and_out:
path_release();
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Chroot bug (was: sys_chroot+sys_fchdir Fix)
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 dynamic libraries, it seems clear that the prime purpose
of chroot is to aid security. Being able to cd your way out is handy
for the bad guys, but the good guys don't need it; there are a thousand
better, safer solutions.
If there truly is a need to be able to pop in and out of a chroot, then
the solution should be obvious, such as with real versus effective user
and group ids. An important quality of a solution would be a way to fix
that essential function: to set the root in such a way that you can no
longer pop out. But that is a separate question.
The question: is chroot buggy? I'm pleased to turn to SCO for an
independent definition for chroot, from which I get the following:
http://osr600doc.sco.com/en/man/html.S/chroot.S.html:
The *..* entry in the root directory is interpreted to mean the root
directory itself. Thus, *..* cannot be used to access files outside
the subtree rooted at the root directory.
I argue chroot is buggy. Miloslav's patch might not be the right
solution, but he has the right idea (i.e. fix it.)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Chroot bug (was: sys_chroot+sys_fchdir Fix)
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 dynamic libraries, it seems clear that the prime purpose of chroot is to aid security. Being able to cd your way out is handy for the bad guys, but the good guys don't need it; there are a thousand better, safer solutions. If there truly is a need to be able to pop in and out of a chroot, then the solution should be obvious, such as with real versus effective user and group ids. An important quality of a solution would be a way to fix that essential function: to set the root in such a way that you can no longer pop out. But that is a separate question. The question: is chroot buggy? I'm pleased to turn to SCO for an independent definition for chroot, from which I get the following: http://osr600doc.sco.com/en/man/html.S/chroot.S.html: The *..* entry in the root directory is interpreted to mean the root directory itself. Thus, *..* cannot be used to access files outside the subtree rooted at the root directory. I argue chroot is buggy. Miloslav's patch might not be the right solution, but he has the right idea (i.e. fix it.) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Chroot bug (was: sys_chroot+sys_fchdir Fix)
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 creative uses, for example Philipp 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 for the bad guys, but the good guys don't need it; there are a thousand better, safer solutions. So what? Just do this: chdir into the root after chroot. It won't conform to SVR4/4.4BSD anymore, but hey, let Linux set some sane standard ain't bad either. I doubt anyone really relies on the fact that after chroot, your cwd might be outside the root. Signed-off-by: Jan Engelhardt [EMAIL PROTECTED] --- fs/open.c |1 + 1 file changed, 1 insertion(+) Index: linux-2.6.23/fs/open.c === --- linux-2.6.23.orig/fs/open.c +++ linux-2.6.23/fs/open.c @@ -547,6 +547,7 @@ asmlinkage long sys_chroot(const char __ set_fs_root(current-fs, nd.mnt, nd.dentry); set_fs_altroot(); + set_fs_pwd(current-fs, nd.mnt, nd.dentry); error = 0; dput_and_out: path_release(nd); - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Chroot bug (was: sys_chroot+sys_fchdir Fix)
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 out of a chroot a million different ways Alan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Chroot bug (was: sys_chroot+sys_fchdir Fix)
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. In addition to any creative uses, for example Philipp 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 for the bad guys, but the good guys don't need it; there are a thousand better, safer solutions. ... The bad guys most likely also now other tricks to escape the chroot. If you are root in the chroot you can e.g. mount the partition with the root filesystem inside the chroot. If a bad guy becomes root inside a chroot it's game over. cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
