From: Paul Moore <paul.moore@hp•com>
To: Andrew Morton <akpm@linux-foundation•org>
Cc: sds@tycho•nsa.gov, jmorris@namei•org, rjw@sisk•pl,
linux-kernel@vger•kernel.org, kernel-testers@vger•kernel.org,
ebiederm@xmission•com, netdev@vger•kernel.org
Subject: Re: [Bug #11500] /proc/net bug related to selinux
Date: Wed, 17 Sep 2008 18:12:59 -0400 [thread overview]
Message-ID: <200809171812.59693.paul.moore@hp.com> (raw)
In-Reply-To: <20080917144842.7df59f9e.akpm@linux-foundation.org>
On Wednesday 17 September 2008 5:48:42 pm Andrew Morton wrote:
> On Wed, 17 Sep 2008 17:24:36 -0400
>
> Paul Moore <paul.moore@hp•com> wrote:
> > On Wednesday 17 September 2008 3:50:53 pm Andrew Morton wrote:
> > > On Mon, 15 Sep 2008 09:05:26 -0400
> > >
> > > Stephen Smalley <sds@tycho•nsa.gov> wrote:
> > > > 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.
> > 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 :)
> > > 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
next prev parent reply other threads:[~2008-09-17 22:12 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <j3zWxt-CgYL.A.WTF.bbsyIB@albercik>
[not found] ` <SpS7rta8n4.A.DCB.IfsyIB@albercik>
2008-09-13 8:47 ` [Bug #11271] BUG: fealnx in 2.6.27-rc1 Jaswinder Singh
[not found] ` <SpS7rta8n4.A.i9G.ZcsyIB@albercik>
[not found] ` <alpine.LRH.1.10.0809130812460.12313@tundra.namei.org>
[not found] ` <20080912152443.c4e59f42.akpm@linux-foundation.org>
[not found] ` <alpine.LRH.1.10.0809131012310.13073@tundra.namei.org>
[not found] ` <20080913123722.e238ae2a.akpm@linux-foundation.org>
[not found] ` <1221483926.30816.18.camel@moss-spartans.epoch.ncsc.mil>
[not found] ` <1221483926.30816.18.camel-/ugcdrsPCSfIm9DtXLC9OUVfdvkotuLY+aIohriVLy8@public.gmane.org>
2008-09-17 19:50 ` [Bug #11500] /proc/net bug related to selinux Andrew Morton
2008-09-17 21:24 ` Paul Moore
2008-09-17 21:39 ` Eric W. Biederman
[not found] ` <m1vdwu4fku.fsf-B27657KtZYmhTnVgQlOflh2eb7JE58TQ@public.gmane.org>
2008-09-17 22:11 ` Andrew Morton
2008-09-17 21:48 ` Andrew Morton
2008-09-17 22:12 ` Paul Moore [this message]
2008-09-17 22:24 ` Andrew Morton
[not found] ` <20080917152407.76230f0c.akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
2008-09-17 22:53 ` Eric W. Biederman
[not found] ` <20080917144842.7df59f9e.akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
2008-09-17 22:32 ` Eric W. Biederman
2008-09-18 12:38 ` Stephen Smalley
2008-09-18 13:03 ` Stephen Smalley
2008-09-18 18:09 ` Eric W. Biederman
2008-09-18 18:34 ` Stephen Smalley
[not found] ` <1221762850.24048.107.camel-/ugcdrsPCSfIm9DtXLC9OUVfdvkotuLY+aIohriVLy8@public.gmane.org>
2008-09-19 16:58 ` david-gFPdbfVZQbY
2008-09-19 17:07 ` Stephen Smalley
2008-09-29 16:49 ` Stephen Smalley
[not found] ` <200809171724.36269.paul.moore-VXdhtT5mjnY@public.gmane.org>
2008-09-17 22:23 ` David Miller
[not found] ` <20080917125053.1f9ecf37.akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
2008-09-17 21:56 ` Eric W. Biederman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200809171812.59693.paul.moore@hp.com \
--to=paul.moore@hp$(echo .)com \
--cc=akpm@linux-foundation$(echo .)org \
--cc=ebiederm@xmission$(echo .)com \
--cc=jmorris@namei$(echo .)org \
--cc=kernel-testers@vger$(echo .)kernel.org \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=netdev@vger$(echo .)kernel.org \
--cc=rjw@sisk$(echo .)pl \
--cc=sds@tycho$(echo .)nsa.gov \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox