Re: [PATCH] tcp: assign the sock correctly to an outgoing SYNACK packet

[Paul Moore <pmoore@redhat.com>]

On Monday, April 08, 2013 11:30:25 AM Eric Dumazet wrote:
> On Mon, 2013-04-08 at 11:21 -0700, Eric Dumazet wrote:
> > On Mon, 2013-04-08 at 14:12 -0400, Paul Moore wrote:
> > > It seems a bit fragile to me, perhaps even hacky, but in some ways I
> > > guess it isn't anymore fragile than relying on skb->sk - as this
> > > problem demonstrates. My other concern is that adding this hook
> > > *correctly* is likely to touch a lot of files and may be a bit much so
> > > late in the 3.9 cycle, Dave, what say you?> 
> > I don't get it, 90ba9b1986b5ac4b2d18 was in 3.6, why do you care of
> > 3.9 ?
> > 
> > I am preparing a fix right now. Not a revert, thank you.
> 
> Is the following patch not good enough ?

I think it is somewhat telling that the hook you're proposing doesn't ever 
make any calls into any of the individual LSMs, it only calls back into the 
networking stack.  In my mind, this makes it an abuse of the LSM mechanism.

On Monday, April 08, 2013 11:34:11 AM Eric Dumazet wrote:
> On Mon, 2013-04-08 at 14:26 -0400, Paul Moore wrote:
> > I guess we'll have to wait and see then; the more I think about the new
> > hook you proposed the less enthused I am about it.
> > 
> > I'm still curious to hear what Dave has to say on this.
> 
> 90ba9b1986b5ac4b2 is 10 months old, and nobody complained until today ?

The people who use this functionality almost never use upstream kernels, they 
need to protection/certification/warm-fuzzies/etc. that come from a 
distribution kernel and a support infrastructure.  I didn't catch it because I 
use a slightly different configuration that didn't expose this bug; while I 
would like to run a full regression test every release I simply don't have the 
time to do that myself.

> This sounds like a very small issue to me, a revert is simply overkill.

It all depends on your use case.  To you, whom I assume doesn't use SELinux, 
it is indeed a trivial issue.  To someone who relies on SELinux for its 
network access controls this is a pretty significant issue.

-- 
paul moore
security and virtualization @ redhat