On 2012-09-30 17:38 -0700, Linus Torvalds wrote:
> So here it is, 3.6 final. Sure, I'd have been happier with even fewer
> changes, but that just never happens. And holding off the release
> until people get too bored to send me the small stuff just makes the
> next merge window more painful.
Just upgraded to 3.6 from 3.5, and now some of my kernel build scripts
are throwing "permission denied" errors. Apparently symlinks are
broken somehow?
# id
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),20(dialout),26(tape),27(video)
# ls -l /scratch_space/linux
drwxr-xr-x 24 nbowler eng 4096 2012-10-03 13:41 /scratch_space/linux
# readlink /scratch_space/linux-2.6
linux
# cd /scratch_space/linux
# pwd
/scratch_space/linux
# cd /scratch_space/linux-2.6
cd: permission denied: /scratch_space/linux-2.6
WTF? 3.5 is fine. I will try to bisect this later, but I figured I'd
throw this out there now in case anyone has any ideas...
Cheers,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
Hi Nick,
3.6 introduced link restrictions:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=800179c9b8a1e796e441674776d11cd4c05d61d7
It sounds like you've got symlinks in a world-writable directory, and
you're following those symlinks across mis-matched uids. You can either
have the symlinks be owned by the directory owner, or you can turn off
symlink restrictions in sysctl:
# echo 0 > /proc/sys/fs/protected_symlinks
-Kees
On Wed, Oct 03, 2012 at 03:46:14PM -0400, Nick Bowler wrote:
> On 2012-09-30 17:38 -0700, Linus Torvalds wrote:
> > So here it is, 3.6 final. Sure, I'd have been happier with even fewer
> > changes, but that just never happens. And holding off the release
> > until people get too bored to send me the small stuff just makes the
> > next merge window more painful.
>
> Just upgraded to 3.6 from 3.5, and now some of my kernel build scripts
> are throwing "permission denied" errors. Apparently symlinks are
> broken somehow?
>
> # id
> uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),20(dialout),26(tape),27(video)
>
> # ls -l /scratch_space/linux
> drwxr-xr-x 24 nbowler eng 4096 2012-10-03 13:41 /scratch_space/linux
>
> # readlink /scratch_space/linux-2.6
> linux
>
> # cd /scratch_space/linux
> # pwd
> /scratch_space/linux
>
> # cd /scratch_space/linux-2.6
> cd: permission denied: /scratch_space/linux-2.6
>
> WTF? 3.5 is fine. I will try to bisect this later, but I figured I'd
> throw this out there now in case anyone has any ideas...
>
> Cheers,
> --
> Nick Bowler, Elliptic Technologies (http://www.elliptictech.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/
--
Kees Cook @outflux.net
On Wed, Oct 3, 2012 at 1:05 PM, Kees Cook <[email protected]> wrote:
>
> 3.6 introduced link restrictions:
Hmm. If this causes problems for others, I suspect we need to turn it
off by default.
It's a nice security thing, but considering how quickly people started
complaining after 3.6 was out, I suspect we'll see more of these, and
we may not have any choice.
Linus
On Wed, Oct 03, 2012 at 01:29:15PM -0700, Linus Torvalds wrote:
> On Wed, Oct 3, 2012 at 1:05 PM, Kees Cook <[email protected]> wrote:
> >
> > 3.6 introduced link restrictions:
>
> Hmm. If this causes problems for others, I suspect we need to turn it
> off by default.
>
> It's a nice security thing, but considering how quickly people started
> complaining after 3.6 was out, I suspect we'll see more of these, and
> we may not have any choice.
True, although I'm not sure we should be encouraging kernel developers
to have world-writeable directories. I suppose if it's a single-user
workstation it wouldn't matter, but you could imagine a daemon running
has "nobody" which has a stack overflow bug, and then if the user has
been careless and uses umasks so that directories in their home
directory are world writeable, well.....
Regardless of whether or not we turn this security feature off by
default, I think it's worthwhile to look at how and why did Nick's
directories become world-writeable, and whether there is so distro
default which is causing or encouraging this.
- Ted
On Wed, 3 Oct 2012 13:05:15 -0700
Kees Cook <[email protected]> wrote:
> Hi Nick,
>
> 3.6 introduced link restrictions:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=800179c9b8a1e796e441674776d11cd4c05d61d7
>
> It sounds like you've got symlinks in a world-writable directory, and
> you're following those symlinks across mis-matched uids. You can either
> have the symlinks be owned by the directory owner, or you can turn off
> symlink restrictions in sysctl:
>
> # echo 0 > /proc/sys/fs/protected_symlinks
Quite honestly that should be pushed for 3.6.1 as a default - ASAP.
Alan
On Wed, Oct 03, 2012 at 04:41:41PM -0400, Theodore Ts'o wrote:
> On Wed, Oct 03, 2012 at 01:29:15PM -0700, Linus Torvalds wrote:
> > On Wed, Oct 3, 2012 at 1:05 PM, Kees Cook <[email protected]> wrote:
> > >
> > > 3.6 introduced link restrictions:
> >
> > Hmm. If this causes problems for others, I suspect we need to turn it
> > off by default.
> >
> > It's a nice security thing, but considering how quickly people started
> > complaining after 3.6 was out, I suspect we'll see more of these, and
> > we may not have any choice.
>
> True, although I'm not sure we should be encouraging kernel developers
> to have world-writeable directories. I suppose if it's a single-user
> workstation it wouldn't matter, but you could imagine a daemon running
> has "nobody" which has a stack overflow bug, and then if the user has
> been careless and uses umasks so that directories in their home
> directory are world writeable, well.....
>
> Regardless of whether or not we turn this security feature off by
> default, I think it's worthwhile to look at how and why did Nick's
> directories become world-writeable, and whether there is so distro
> default which is causing or encouraging this.
I think the benefits of this being on by default outweigh glitches
like this. Based on Nick's email, it looks like a directory tree of his
own creation.
-Kees
--
Kees Cook @outflux.net
On Wed, Oct 3, 2012 at 1:49 PM, Kees Cook <[email protected]> wrote:
>
> I think the benefits of this being on by default outweigh glitches
> like this. Based on Nick's email, it looks like a directory tree of his
> own creation.
I agree that *one* report like this doesn't necessarily mean that we
need to turn it off, if Nick is happy to just fix up his script and
it's all local.
However, I suspect we'll see more. And once that happens, we're not
going to keep a default that breaks peoples old scripts, and we're
going to have to rely on distributions (or users) explicitly setting
it.
Compatibility is just too important.
Linus
On Wed, Oct 03, 2012 at 01:54:21PM -0700, Linus Torvalds wrote:
> On Wed, Oct 3, 2012 at 1:49 PM, Kees Cook <[email protected]> wrote:
> >
> > I think the benefits of this being on by default outweigh glitches
> > like this. Based on Nick's email, it looks like a directory tree of his
> > own creation.
>
> I agree that *one* report like this doesn't necessarily mean that we
> need to turn it off, if Nick is happy to just fix up his script and
> it's all local.
>
> However, I suspect we'll see more. And once that happens, we're not
> going to keep a default that breaks peoples old scripts, and we're
> going to have to rely on distributions (or users) explicitly setting
> it.
>
> Compatibility is just too important.
If this happens, I _really_ want to bring back the CONFIG options I had in
an earlier version of this patch. I want to be able to declare the default
at build time, and not leave a system vulnerable from boot until sysctls
get set.
-Kees
--
Kees Cook @outflux.net
> If this happens, I _really_ want to bring back the CONFIG options I had in
> an earlier version of this patch. I want to be able to declare the default
> at build time, and not leave a system vulnerable from boot until sysctls
> get set.
If your early boot code trusts a random writeable user directory I think
you have other problems.
On Wed, Oct 03, 2012 at 10:05:25PM +0100, Alan Cox wrote:
> > If this happens, I _really_ want to bring back the CONFIG options I had in
> > an earlier version of this patch. I want to be able to declare the default
> > at build time, and not leave a system vulnerable from boot until sysctls
> > get set.
>
> If your early boot code trusts a random writeable user directory I think
> you have other problems.
You should see some of the things various Android devices do! :)
-Kees
--
Kees Cook @outflux.net
On 03.10.2012 13:05, Kees Cook wrote:
> Hi Nick,
>
> 3.6 introduced link restrictions:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=800179c9b8a1e796e441674776d11cd4c05d61d7
>
> It sounds like you've got symlinks in a world-writable directory, and
> you're following those symlinks across mis-matched uids. You can either
> have the symlinks be owned by the directory owner, or you can turn off
> symlink restrictions in sysctl:
>
> # echo 0 > /proc/sys/fs/protected_symlinks
According to documentation world writable isn't the problem.
It's world writable inside/or below a directory with sticky bit.
(Documentation/sysctl/fs.txt -> protected_symlinks)
So /scratch_space must have the sticky bit set.
Question is: Why?
Personally i would have been bitten by this change, because for years i
have used a symlink in /tmp (which has the sticky bit) to a directory
somewhere else for historical reasons. But as i was aware of this change
i fixed my system before booting the new kernel.
> On Wed, Oct 03, 2012 at 03:46:14PM -0400, Nick Bowler wrote:
> > On 2012-09-30 17:38 -0700, Linus Torvalds wrote:
> > > So here it is, 3.6 final. Sure, I'd have been happier with even fewer
> > > changes, but that just never happens. And holding off the release
> > > until people get too bored to send me the small stuff just makes the
> > > next merge window more painful.
> >
> > Just upgraded to 3.6 from 3.5, and now some of my kernel build scripts
> > are throwing "permission denied" errors. Apparently symlinks are
> > broken somehow?
> >
> > # id
> > uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),20(dialout),26(tape),27(video)
> >
> > # ls -l /scratch_space/linux
> > drwxr-xr-x 24 nbowler eng 4096 2012-10-03 13:41 /scratch_space/linux
> >
> > # readlink /scratch_space/linux-2.6
> > linux
> >
> > # cd /scratch_space/linux
> > # pwd
> > /scratch_space/linux
> >
> > # cd /scratch_space/linux-2.6
> > cd: permission denied: /scratch_space/linux-2.6
> >
> > WTF? 3.5 is fine. I will try to bisect this later, but I figured I'd
> > throw this out there now in case anyone has any ideas...
Bis denn
--
Real Programmers consider "what you see is what you get" to be just as
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated,
cryptic, powerful, unforgiving, dangerous.
On Thu, Oct 04, 2012 at 12:23:41AM +0200, Matthias Schniedermeyer wrote:
> Personally i would have been bitten by this change, because for years i
> have used a symlink in /tmp (which has the sticky bit) to a directory
> somewhere else for historical reasons. But as i was aware of this change
> i fixed my system before booting the new kernel.
As long as you own the symlink, it wouldn't be a problem. The problem
comes when the symlink is owned by some user such as
"untrusted_daemon", which could change where the symlink could point
at any any time --- or could create a new symlink where none had
previously existed in some world-writeable directory such as /tmp.
Now you try to use that symlink, assuming that it points to *foo*,
when in fact it now points to *bar*, and hilarity ensues...
- Ted
On 2012-10-03 13:54 -0700, Linus Torvalds wrote:
> On Wed, Oct 3, 2012 at 1:49 PM, Kees Cook <[email protected]> wrote:
> > I think the benefits of this being on by default outweigh glitches
> > like this. Based on Nick's email, it looks like a directory tree of his
> > own creation.
>
> I agree that *one* report like this doesn't necessarily mean that we
> need to turn it off, if Nick is happy to just fix up his script and
> it's all local.
>
> However, I suspect we'll see more. And once that happens, we're not
> going to keep a default that breaks peoples old scripts, and we're
> going to have to rely on distributions (or users) explicitly setting
> it.
Yes, it is a directory of my own creation, intended as a place for users
(read: me) to stick stuff on the local disk as opposed to on NFS. It's
pretty trivial for me to fixup everything to not need this symlink
anymore (and I suspect it is the only offender); I just created the
symlink in the first place so that I wouldn't have to change anything
else.
(While on /this/ machine I created the directory, I have used shared lab
machines with a similar setup).
The thing that bothers me most about all this is that it's basically
impossible to see why things are failing without digging through the git
tree or posting to the mailing list (or recalling earlier mailing list
discussions about the restriction, as I vaguely do now). You just
suddenly get "permission denied" errors when all the permissions
involved look fine. As far as I know, the owner, group and mode of
symlinks have always been completely meaningless. Upgrade to 3.6, and
they're suddenly meaningful in extremely non-obvious ways.
Cheers,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
On Thu, Oct 04, 2012 at 09:35:04AM -0400, Nick Bowler wrote:
> On 2012-10-03 13:54 -0700, Linus Torvalds wrote:
> > On Wed, Oct 3, 2012 at 1:49 PM, Kees Cook <[email protected]> wrote:
> > > I think the benefits of this being on by default outweigh glitches
> > > like this. Based on Nick's email, it looks like a directory tree of his
> > > own creation.
> >
> > I agree that *one* report like this doesn't necessarily mean that we
> > need to turn it off, if Nick is happy to just fix up his script and
> > it's all local.
> >
> > However, I suspect we'll see more. And once that happens, we're not
> > going to keep a default that breaks peoples old scripts, and we're
> > going to have to rely on distributions (or users) explicitly setting
> > it.
>
> Yes, it is a directory of my own creation, intended as a place for users
> (read: me) to stick stuff on the local disk as opposed to on NFS. It's
> pretty trivial for me to fixup everything to not need this symlink
> anymore (and I suspect it is the only offender); I just created the
> symlink in the first place so that I wouldn't have to change anything
> else.
>
> (While on /this/ machine I created the directory, I have used shared lab
> machines with a similar setup).
>
> The thing that bothers me most about all this is that it's basically
> impossible to see why things are failing without digging through the git
> tree or posting to the mailing list (or recalling earlier mailing list
> discussions about the restriction, as I vaguely do now). You just
> suddenly get "permission denied" errors when all the permissions
> involved look fine. As far as I know, the owner, group and mode of
> symlinks have always been completely meaningless. Upgrade to 3.6, and
> they're suddenly meaningful in extremely non-obvious ways.
FWIW, there should have been an audit message about it in dmesg.
-Kees
--
Kees Cook @outflux.net
On 2012-10-04 08:49 -0700, Kees Cook wrote:
> On Thu, Oct 04, 2012 at 09:35:04AM -0400, Nick Bowler wrote:
> > On 2012-10-03 13:54 -0700, Linus Torvalds wrote:
> > > On Wed, Oct 3, 2012 at 1:49 PM, Kees Cook <[email protected]> wrote:
> > > > I think the benefits of this being on by default outweigh glitches
> > > > like this. Based on Nick's email, it looks like a directory tree of his
> > > > own creation.
> > >
> > > I agree that *one* report like this doesn't necessarily mean that we
> > > need to turn it off, if Nick is happy to just fix up his script and
> > > it's all local.
> > >
> > > However, I suspect we'll see more. And once that happens, we're not
> > > going to keep a default that breaks peoples old scripts, and we're
> > > going to have to rely on distributions (or users) explicitly setting
> > > it.
> >
> > Yes, it is a directory of my own creation, intended as a place for users
> > (read: me) to stick stuff on the local disk as opposed to on NFS. It's
> > pretty trivial for me to fixup everything to not need this symlink
> > anymore (and I suspect it is the only offender); I just created the
> > symlink in the first place so that I wouldn't have to change anything
> > else.
> >
> > (While on /this/ machine I created the directory, I have used shared lab
> > machines with a similar setup).
> >
> > The thing that bothers me most about all this is that it's basically
> > impossible to see why things are failing without digging through the git
> > tree or posting to the mailing list (or recalling earlier mailing list
> > discussions about the restriction, as I vaguely do now). You just
> > suddenly get "permission denied" errors when all the permissions
> > involved look fine. As far as I know, the owner, group and mode of
> > symlinks have always been completely meaningless. Upgrade to 3.6, and
> > they're suddenly meaningful in extremely non-obvious ways.
>
> FWIW, there should have been an audit message about it in dmesg.
There were zero messages in the kernel log.
# dmesg -C
# cd /tmp
# mkdir testdir
# ln -s testdir testlink
# chown -h nobody testlink
# cd testlink
cd: permission denied: testlink
# dmesg
(no output)
Cheers,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
On Thu, Oct 04, 2012 at 12:03:54PM -0400, Nick Bowler wrote:
> On 2012-10-04 08:49 -0700, Kees Cook wrote:
> > On Thu, Oct 04, 2012 at 09:35:04AM -0400, Nick Bowler wrote:
> > > On 2012-10-03 13:54 -0700, Linus Torvalds wrote:
> > > > On Wed, Oct 3, 2012 at 1:49 PM, Kees Cook <[email protected]> wrote:
> > > > > I think the benefits of this being on by default outweigh glitches
> > > > > like this. Based on Nick's email, it looks like a directory tree of his
> > > > > own creation.
> > > >
> > > > I agree that *one* report like this doesn't necessarily mean that we
> > > > need to turn it off, if Nick is happy to just fix up his script and
> > > > it's all local.
> > > >
> > > > However, I suspect we'll see more. And once that happens, we're not
> > > > going to keep a default that breaks peoples old scripts, and we're
> > > > going to have to rely on distributions (or users) explicitly setting
> > > > it.
> > >
> > > Yes, it is a directory of my own creation, intended as a place for users
> > > (read: me) to stick stuff on the local disk as opposed to on NFS. It's
> > > pretty trivial for me to fixup everything to not need this symlink
> > > anymore (and I suspect it is the only offender); I just created the
> > > symlink in the first place so that I wouldn't have to change anything
> > > else.
> > >
> > > (While on /this/ machine I created the directory, I have used shared lab
> > > machines with a similar setup).
> > >
> > > The thing that bothers me most about all this is that it's basically
> > > impossible to see why things are failing without digging through the git
> > > tree or posting to the mailing list (or recalling earlier mailing list
> > > discussions about the restriction, as I vaguely do now). You just
> > > suddenly get "permission denied" errors when all the permissions
> > > involved look fine. As far as I know, the owner, group and mode of
> > > symlinks have always been completely meaningless. Upgrade to 3.6, and
> > > they're suddenly meaningful in extremely non-obvious ways.
> >
> > FWIW, there should have been an audit message about it in dmesg.
>
> There were zero messages in the kernel log.
>
> # dmesg -C
> # cd /tmp
> # mkdir testdir
> # ln -s testdir testlink
> # chown -h nobody testlink
> # cd testlink
> cd: permission denied: testlink
> # dmesg
> (no output)
Well that's sad. :( Two situations I can think of for that:
- the kernel wasn't build with CONFIG_AUDIT
- auditd is running and hiding the notices in some other log file
-Kees
--
Kees Cook @outflux.net
On 2012-10-04 09:14 -0700, Kees Cook wrote:
> On Thu, Oct 04, 2012 at 12:03:54PM -0400, Nick Bowler wrote:
> > On 2012-10-04 08:49 -0700, Kees Cook wrote:
> > > On Thu, Oct 04, 2012 at 09:35:04AM -0400, Nick Bowler wrote:
[...]
> > > > The thing that bothers me most about all this is that it's basically
> > > > impossible to see why things are failing without digging through the git
> > > > tree or posting to the mailing list (or recalling earlier mailing list
> > > > discussions about the restriction, as I vaguely do now). You just
> > > > suddenly get "permission denied" errors when all the permissions
> > > > involved look fine. As far as I know, the owner, group and mode of
> > > > symlinks have always been completely meaningless. Upgrade to 3.6, and
> > > > they're suddenly meaningful in extremely non-obvious ways.
> > >
> > > FWIW, there should have been an audit message about it in dmesg.
> >
> > There were zero messages in the kernel log.
> >
> > # dmesg -C
> > # cd /tmp
> > # mkdir testdir
> > # ln -s testdir testlink
> > # chown -h nobody testlink
> > # cd testlink
> > cd: permission denied: testlink
> > # dmesg
> > (no output)
>
> Well that's sad. :( Two situations I can think of for that:
> - the kernel wasn't build with CONFIG_AUDIT
Indeed, I do not have this option enabled. Why would I have it? The
description says it's for SELinux, which I do not use.
Cheers,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
On Oct 04 Nick Bowler wrote:
> On 2012-10-04 09:14 -0700, Kees Cook wrote:
> > On Thu, Oct 04, 2012 at 12:03:54PM -0400, Nick Bowler wrote:
> > > On 2012-10-04 08:49 -0700, Kees Cook wrote:
> > > > FWIW, there should have been an audit message about it in dmesg.
> > >
> > > There were zero messages in the kernel log.
> > >
> > > # dmesg -C
> > > # cd /tmp
> > > # mkdir testdir
> > > # ln -s testdir testlink
> > > # chown -h nobody testlink
> > > # cd testlink
> > > cd: permission denied: testlink
> > > # dmesg
> > > (no output)
> >
> > Well that's sad. :( Two situations I can think of for that:
> > - the kernel wasn't build with CONFIG_AUDIT
>
> Indeed, I do not have this option enabled. Why would I have it? The
> description says it's for SELinux, which I do not use.
It says it is /among else/ for SELinux. Another user appears to be
ConsoleKit, which wants CONFIG_AUDITSYSCALL, which depends on CONFIG_AUDIT.
--
Stefan Richter
-=====-===-- =-=- --=--
http://arcgraph.de/sr/
On 2012-10-04 23:30 +0200, Stefan Richter wrote:
> On Oct 04 Nick Bowler wrote:
> > On 2012-10-04 09:14 -0700, Kees Cook wrote:
> > > On Thu, Oct 04, 2012 at 12:03:54PM -0400, Nick Bowler wrote:
> > > > On 2012-10-04 08:49 -0700, Kees Cook wrote:
> > > > > FWIW, there should have been an audit message about it in dmesg.
[...]
> > > > # dmesg
> > > > (no output)
> > >
> > > Well that's sad. :( Two situations I can think of for that:
> > > - the kernel wasn't build with CONFIG_AUDIT
> >
> > Indeed, I do not have this option enabled. Why would I have it? The
> > description says it's for SELinux, which I do not use.
>
> It says it is /among else/ for SELinux. Another user appears to be
> ConsoleKit, which wants CONFIG_AUDITSYSCALL, which depends on CONFIG_AUDIT.
Indeed, you are correct that the help text does imply that there are
(potentially) other users besides SElinux, although it does not say what
they are. Regardless, the point is that I have no idea why I would have
this optional feature enabled, as I still don't even know what it does
because the help text doesn't actually say. I even found a website,
http://people.redhat.com/sgrubb/audit/, which seems to be related to
this feature but even here I cannot find one sentence explaining what
the feature is.
Well, from this thread I now know that this feature enables, at least
in some cases, printk messages when your previously-working scripts are
broken by a kernel update.
Cheers,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)