From: Luke Kenneth Casson Leighton <lkcl@lkcl.net>
To: Chris Wright <chrisw@osdl.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [patch] update: _working_ code to add device+inode check to ipt_owner.c
Date: Fri, 10 Sep 2004 02:34:45 +0100 [thread overview]
Message-ID: <20040910013445.GF11160@lkcl.net> (raw)
In-Reply-To: <20040909180838.H1924@build.pdx.osdl.net>
On Thu, Sep 09, 2004 at 06:08:38PM -0700, Chris Wright wrote:
> * Luke Kenneth Casson Leighton (lkcl@lkcl.net) 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?
hmmm... *thinks*...
thought-experiment:
it'd involve doing a userspace rule that caught the packet.
> > [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.
*neck muscles tensing causing head to vibrate at about 8Hz*
rrrrrr arg!
okay - chris, anyone - got any tips on triggering socket lookup?
what sort of things should i be looking for in netfilter that does
the socket lookup?
next prev parent reply other threads:[~2004-09-10 1:23 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-09 16:22 [patch] update: _working_ code to add device+inode check to ipt_owner.c Luke Kenneth Casson Leighton
2004-09-09 16:19 ` Chris Wright
2004-09-09 18:10 ` Luke Kenneth Casson Leighton
2004-09-09 18:48 ` Chris Wright
2004-09-09 21:25 ` Luke Kenneth Casson Leighton
2004-09-09 23:04 ` Chris Wright
2004-09-10 0:08 ` Luke Kenneth Casson Leighton
2004-09-10 0:21 ` Chris Wright
2004-09-10 0:59 ` Luke Kenneth Casson Leighton
2004-09-10 1:08 ` Chris Wright
2004-09-10 1:34 ` Luke Kenneth Casson Leighton [this message]
2004-09-09 21:38 ` Luke Kenneth Casson Leighton
2004-09-09 23:41 ` Chris Wright
2004-09-10 0:10 ` Luke Kenneth Casson Leighton
2004-09-09 16:29 ` Stephen Smalley
2004-09-09 16:33 ` Stephen Smalley
2004-09-09 17:44 ` Luke Kenneth Casson Leighton
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=20040910013445.GF11160@lkcl.net \
--to=lkcl@lkcl.net \
--cc=chrisw@osdl.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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