I think this might be a regression caused by namespace changes which we
By which I mean, this was caused by a non-SELinux change to the upstream
kernel many, many eons ago.
hm, seems that 2.6.24 is OK but 2.6.25 is not. I must have missed the
bug when testing 2.6.25-based kernels.
I started a git bisection search but after half an hour I hit bad
bisection breakage: a complete machine hang in fib_rules_init().
quoted
quoted
quoted
addressed in SELinux policy. Which distro version & policy version is
this seen with?
FC5 on x86_32 and FC6 on x86_64.
As mentioned in the bugzilla, any related avc messages would be useful.
2.6.25 dmesg: http://userweb.kernel.org/~akpm/dmesg-sony.txt
/var/log/messages: http://userweb.kernel.org/~akpm/messages-sony.txt
The latter includes this:
Sep 13 12:32:43 sony kernel: SELinux: class key not defined in policy
Sep 13 12:32:43 sony kernel: SELinux: class dccp_socket not defined in policy
Sep 13 12:32:43 sony kernel: SELinux: class memprotect not defined in policy
Sep 13 12:32:43 sony kernel: SELinux: class peer not defined in policy
Sep 13 12:32:43 sony kernel: SELinux: class capability2 not defined in policy
Sep 13 12:32:43 sony kernel: SELinux: permission open in class dir not defined in policy
Sep 13 12:32:43 sony kernel: SELinux: permission open in class file not defined in policy
Sep 13 12:32:43 sony kernel: SELinux: permission open in class chr_file not defined in policy
Sep 13 12:32:43 sony kernel: SELinux: permission open in class blk_file not defined in policy
Sep 13 12:32:43 sony kernel: SELinux: permission open in class fifo_file not defined in policy
Sep 13 12:32:43 sony kernel: SELinux: permission dccp_recv in class node not defined in policy
Sep 13 12:32:43 sony kernel: SELinux: permission dccp_send in class node not defined in policy
Sep 13 12:32:43 sony kernel: SELinux: permission recvfrom in class node not defined in policy
Sep 13 12:32:43 sony kernel: SELinux: permission sendto in class node not defined in policy
Sep 13 12:32:43 sony kernel: SELinux: permission dccp_recv in class netif not defined in policy
Sep 13 12:32:43 sony kernel: SELinux: permission dccp_send in class netif not defined in policy
Sep 13 12:32:43 sony kernel: SELinux: permission ingress in class netif not defined in policy
Sep 13 12:32:43 sony kernel: SELinux: permission egress in class netif not defined in policy
Sep 13 12:32:44 sony kernel: SELinux: permission setkeycreate in class process not defined in policy
Sep 13 12:32:44 sony kernel: SELinux: permission setsockcreate in class process not defined in policy
Sep 13 12:32:44 sony kernel: SELinux: permission setfcap in class capability not defined in policy
Sep 13 12:32:44 sony kernel: SELinux: permission polmatch in class association not defined in policy
Sep 13 12:32:44 sony kernel: SELinux: permission flow_in in class packet not defined in policy
Sep 13 12:32:44 sony kernel: SELinux: permission flow_out in class packet not defined in policy
Sep 13 12:32:44 sony kernel: SELinux: permission forward_in in class packet not defined in policy
Sep 13 12:32:44 sony kernel: SELinux: permission forward_out in class packet not defined in policy
Sep 13 12:32:44 sony kernel: SELinux: the above unknown classes and permissions will be denied
Sep 13 12:32:44 sony kernel: type=1403 audit(1221309118.644:3): policy loaded auid=4294967295 ses=4294967295
Sep 13 12:32:44 sony kernel: type=1400 audit(1221334321.726:4): avc: denied { audit_write } for pid=400 comm="hwclock" capability=29 scontext=system_u:system_r:hwclock_t:s0 tcontext=system_u:system_r:hwclock_t:s0 tclass=capability
Why am I seeing this on two machines and two vanilla-installed distros
but nobody else is reporting it?
Running `ls -l /proc/net' on the FC6 machine produces:
[ 132.591215] type=1400 audit(1221679672.590:10): avc: denied { getattr } for pid=4389 comm="ls" path="/proc/net" dev=proc ino=4026531867 scontext=user_u:system_r:unconfined_t:s0 tcontext=system_u:object_r:proc_net_t:s0 tclass=lnk_file
What we actually need to see is the output of:
/sbin/ausearch -i -m AVC -sv no
akpm2:/home/akpm# /sbin/ausearch -i -m AVC -sv no
<no matches>
However, the most likely explanation is simply that when /proc/net was
changed from being a directory to being a symlink to /proc/self/net,
that introduced an additional permission check on accesses
of /proc/net/<whatever>, namely the read check on the symlink itself.
And since that check wasn't happening on /proc/net accesses with older
kernels, older policies didn't allow it.
As to why others haven't reported it, I expect that they have updated
their policies to newer ones that allow the necessary access. The fact
that legacy distros wouldn't have such updated policies isn't surprising
- they don't push updates to those distros for new kernels. FC5 and FC6
are both EOL'd, right?
In any event, we didn't change anything in SELinux - the change was
elsewhere (in the proc/net implementation). Don't blame the messenger
please.
Vanilla FC5 broke and vanilla FC6 broke. Did vanilla FC7, 8 or 9 break?
http://smolt.fedoraproject.org/static/stats/stats.html shows 11,000-odd
people running FC5 and FC6. It would be incautious to assume that all
those people have updated their selinux rules.
And _requiring_ people to update their selinux rules to fix a
kernel-caused regression is a pretty big deal for some people, I
expect.
Then again, given that this regression has been out there since 2.6.25,
I guess not too many people are hurting from it. But we suck.
From: Paul Moore <hidden> Date: 2008-09-17 21:24:59
On Wednesday 17 September 2008 3:50:53 pm Andrew Morton wrote:
On Mon, 15 Sep 2008 09:05:26 -0400
Stephen Smalley [off-list ref] wrote:
quoted
However, the most likely explanation is simply that when /proc/net
was changed from being a directory to being a symlink to
/proc/self/net, that introduced an additional permission check on
accesses of /proc/net/<whatever>, namely the read check on the
symlink itself. And since that check wasn't happening on /proc/net
accesses with older kernels, older policies didn't allow it.
As to why others haven't reported it, I expect that they have
updated their policies to newer ones that allow the necessary
access. The fact that legacy distros wouldn't have such updated
policies isn't surprising - they don't push updates to those
distros for new kernels. FC5 and FC6 are both EOL'd, right?
In any event, we didn't change anything in SELinux - the change was
elsewhere (in the proc/net implementation). Don't blame the
messenger please.
Vanilla FC5 broke and vanilla FC6 broke. Did vanilla FC7, 8 or 9
break?
http://smolt.fedoraproject.org/static/stats/stats.html shows
11,000-odd people running FC5 and FC6. It would be incautious to
assume that all those people have updated their selinux rules.
And _requiring_ people to update their selinux rules to fix a
kernel-caused regression is a pretty big deal for some people, I
expect.
Just so I'm clear on the context of the problem, it sounds like if a FC5
(I'm limiting myself to FC5 for the moment) user upgraded to a recent
(2.6.25+) kernel (non-distro supplied in the case of FC5) then they
will run into problems unless they also upgrade their SELinux policy,
yes?
If that is the case I'm not sure it is really that big of a deal. Maybe
I'm in the minority here, but in my mind once you step away from the
distro supplied kernel (also applies to other packages, although those
are arguably less critical) you should also bear the responsibility to
make sure you upgrade/tweak/install whatever other bits need to be
fixed.
Then again, given that this regression has been out there since
2.6.25, I guess not too many people are hurting from it. But we
suck.
We suck? Maybe, but some explanation about why we suck in this
particular case would be helpful as far as I'm concerned. I don't
really care about identifying the guilty suckees, I'm more interested
in finding out what happened to cause us to suck because of this.
--
paul moore
linux @ hp
From: Andrew Morton <akpm@linux-foundation.org> Date: 2008-09-17 21:49:38
On Wed, 17 Sep 2008 17:24:36 -0400
Paul Moore [off-list ref] wrote:
On Wednesday 17 September 2008 3:50:53 pm Andrew Morton wrote:
quoted
On Mon, 15 Sep 2008 09:05:26 -0400
Stephen Smalley [off-list ref] wrote:
quoted
However, the most likely explanation is simply that when /proc/net
was changed from being a directory to being a symlink to
/proc/self/net, that introduced an additional permission check on
accesses of /proc/net/<whatever>, namely the read check on the
symlink itself. And since that check wasn't happening on /proc/net
accesses with older kernels, older policies didn't allow it.
As to why others haven't reported it, I expect that they have
updated their policies to newer ones that allow the necessary
access. The fact that legacy distros wouldn't have such updated
policies isn't surprising - they don't push updates to those
distros for new kernels. FC5 and FC6 are both EOL'd, right?
In any event, we didn't change anything in SELinux - the change was
elsewhere (in the proc/net implementation). Don't blame the
messenger please.
Vanilla FC5 broke and vanilla FC6 broke. Did vanilla FC7, 8 or 9
break?
http://smolt.fedoraproject.org/static/stats/stats.html shows
11,000-odd people running FC5 and FC6. It would be incautious to
assume that all those people have updated their selinux rules.
And _requiring_ people to update their selinux rules to fix a
kernel-caused regression is a pretty big deal for some people, I
expect.
Just so I'm clear on the context of the problem, it sounds like if a FC5
(I'm limiting myself to FC5 for the moment) user upgraded to a recent
(2.6.25+) kernel (non-distro supplied in the case of FC5) then they
will run into problems unless they also upgrade their SELinux policy,
yes?
That only true if the 2.6.25+ kernel.org kernel is
backward-incompatible with the distro kernel.
If that is the case I'm not sure it is really that big of a deal. Maybe
I'm in the minority here, but in my mind once you step away from the
distro supplied kernel (also applies to other packages, although those
are arguably less critical) you should also bear the responsibility to
make sure you upgrade/tweak/install whatever other bits need to be
fixed.
Nope. Releasing a non-backward-compatible kernel.org kernel is a big
deal.
We'll do it sometimes, with long notice, much care and much deliberation.
We did it this time by sheer accident. That's known in the trade as a
"bug".
quoted
Then again, given that this regression has been out there since
2.6.25, I guess not too many people are hurting from it. But we
suck.
We suck? Maybe, but some explanation about why we suck in this
particular case would be helpful as far as I'm concerned. I don't
really care about identifying the guilty suckees, I'm more interested
in finding out what happened to cause us to suck because of this.
Because we unintentionally and unknowingly released a kernel which is
not compatible with previous kernels without notifying any of our users
and without any consideration or planning.
Yes, often the consequences of the screwup are fairly small, but it's a
screwup nonetheless.
We don't even know the extent of the damage yet. Which distros were
affected? With which versions of which userspace packages?
From: Paul Moore <hidden> Date: 2008-09-17 22:13:21
On Wednesday 17 September 2008 5:48:42 pm Andrew Morton wrote:
On Wed, 17 Sep 2008 17:24:36 -0400
Paul Moore [off-list ref] wrote:
quoted
On Wednesday 17 September 2008 3:50:53 pm Andrew Morton wrote:
quoted
On Mon, 15 Sep 2008 09:05:26 -0400
Stephen Smalley [off-list ref] wrote:
quoted
However, the most likely explanation is simply that when
/proc/net was changed from being a directory to being a symlink
to /proc/self/net, that introduced an additional permission
check on accesses of /proc/net/<whatever>, namely the read
check on the symlink itself. And since that check wasn't
happening on /proc/net accesses with older kernels, older
policies didn't allow it.
As to why others haven't reported it, I expect that they have
updated their policies to newer ones that allow the necessary
access. The fact that legacy distros wouldn't have such
updated policies isn't surprising - they don't push updates to
those distros for new kernels. FC5 and FC6 are both EOL'd,
right?
In any event, we didn't change anything in SELinux - the change
was elsewhere (in the proc/net implementation). Don't blame
the messenger please.
Vanilla FC5 broke and vanilla FC6 broke. Did vanilla FC7, 8 or 9
break?
http://smolt.fedoraproject.org/static/stats/stats.html shows
11,000-odd people running FC5 and FC6. It would be incautious to
assume that all those people have updated their selinux rules.
And _requiring_ people to update their selinux rules to fix a
kernel-caused regression is a pretty big deal for some people, I
expect.
Just so I'm clear on the context of the problem, it sounds like if
a FC5 (I'm limiting myself to FC5 for the moment) user upgraded to
a recent (2.6.25+) kernel (non-distro supplied in the case of FC5)
then they will run into problems unless they also upgrade their
SELinux policy, yes?
That only true if the 2.6.25+ kernel.org kernel is
backward-incompatible with the distro kernel.
Yep, just wanted to make sure I was understanding the problem correctly.
quoted
If that is the case I'm not sure it is really that big of a deal.
Maybe I'm in the minority here, but in my mind once you step away
from the distro supplied kernel (also applies to other packages,
although those are arguably less critical) you should also bear the
responsibility to make sure you upgrade/tweak/install whatever
other bits need to be fixed.
Nope. Releasing a non-backward-compatible kernel.org kernel is a big
deal.
Well, there is also the issue of distro specific "special sauce" patches
which might cause different behavior from the kernel.org kernel, but
now we are starting to do down a rat hole ...
We'll do it sometimes, with long notice, much care and much
deliberation.
We did it this time by sheer accident. That's known in the trade as
a "bug".
It is somewhat comforting to know that we can call what we do a "trade",
further commentary on my part is best left to the imagination :)
quoted
quoted
Then again, given that this regression has been out there since
2.6.25, I guess not too many people are hurting from it. But we
suck.
We suck? Maybe, but some explanation about why we suck in this
particular case would be helpful as far as I'm concerned. I don't
really care about identifying the guilty suckees, I'm more
interested in finding out what happened to cause us to suck because
of this.
Because we unintentionally and unknowingly released a kernel which is
not compatible with previous kernels without notifying any of our
users and without any consideration or planning.
Yes, often the consequences of the screwup are fairly small, but it's
a screwup nonetheless.
Okay, so we suck because broke something in 2.6.25 that went undetected
because current SELinux policies happen to be compatible with the
breakage. Gotcha.
We don't even know the extent of the damage yet. Which distros were
affected? With which versions of which userspace packages?
Can I assume that the "right" thing to do would be to find the problem
and revert whatever change caused the issue, yes? Or are we happy to
wait and see since the fallout so far has been minimal?
--
paul moore
linux @ hp
From: Andrew Morton <akpm@linux-foundation.org> Date: 2008-09-17 22:25:20
On Wed, 17 Sep 2008 18:12:59 -0400
Paul Moore [off-list ref] wrote:
quoted
We don't even know the extent of the damage yet. Which distros were
affected? With which versions of which userspace packages?
Can I assume that the "right" thing to do would be to find the problem
and revert whatever change caused the issue, yes? Or are we happy to
wait and see since the fallout so far has been minimal?
I don't think a revert is justified after all this time. afaik I'm the
first person to notice the problem, and it's been out there for
multiple months.
However it would be good if we could find some not-completely-stinky
way of making the old userspace work.
otoh, people who are shipping 2.6.25- and 2.6.26-based distros probably
wouldn't want such a patch in their kernels anyway.
From: David Miller <davem@davemloft.net> Date: 2008-09-17 22:23:37
From: Paul Moore <redacted>
Date: Wed, 17 Sep 2008 17:24:36 -0400
If that is the case I'm not sure it is really that big of a deal. Maybe
I'm in the minority here, but in my mind once you step away from the
distro supplied kernel (also applies to other packages, although those
are arguably less critical) you should also bear the responsibility to
make sure you upgrade/tweak/install whatever other bits need to be
fixed.