Re: [patch] update: _working_ code to add device+inode check to ipt_owner.c

[Chris Wright]

* Luke Kenneth Casson Leighton (lkcl@xxxxxxxx) wrote:
> On Thu, Sep 09, 2004 at 05:21:35PM -0700, Chris Wright wrote:
> > >  under such circumstances [file descs passed between programs]...
> > >  you would end up having to create _two_ program-specific rules, like
> > >  above.
> > > 
> > >  one for each of the two programs.
> > 
> > Actually you wouldn't, just one.  It will match, then one of those
> > processes will get woken up and receive the data, regardless of whether
> > you meant to allow it.  
> 
>  blehhrrr....
> 
>  oh i get it.  
>  
>  is that like someone writing really poor quality code where
>  you have two processes reading from the same socket, wot like
>  you're not supposed to do?

I don't think it's behaviour many apps rely on.  But this is exactly the
kind of behaviour which can break security models.

>  or are there real instances / times where you really _do_ want
>  that sort of thing to happen (xinetd?)

Well, xinted won't really read from multiple processes simultaneously
(if all is working properly).  The xinetd server will see the initial
packet, then fork/exec and close off all extra fds.  Now, try and write
a firewall ruleset that mandatorily enforces that.  See the trouble?

>  [btw the sk_socket->file thing isn't filled in on input packets,
>   but you still get the packet.  arg.  how the heck does ip_queue
>   get enough info???]

Heh, right.  The sock is protocol specific.  The input happening on ip
level is before sock lookup.

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/