From: Chris Wright <chrisw@osdl.org>
To: Luke Kenneth Casson Leighton <lkcl@lkcl.net>
Cc: Chris Wright <chrisw@osdl.org>, linux-kernel@vger.kernel.org
Subject: Re: [patch] update: _working_ code to add device+inode check to ipt_owner.c
Date: Thu, 9 Sep 2004 18:08:38 -0700 [thread overview]
Message-ID: <20040909180838.H1924@build.pdx.osdl.net> (raw)
In-Reply-To: <20040910005932.GA11160@lkcl.net>; from lkcl@lkcl.net on Fri, Sep 10, 2004 at 01:59:32AM +0100
* 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?
> [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
next prev parent reply other threads:[~2004-09-10 1:08 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-09 16:22 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 [this message]
2004-09-10 1:34 ` Luke Kenneth Casson Leighton
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=20040909180838.H1924@build.pdx.osdl.net \
--to=chrisw@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lkcl@lkcl.net \
/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
all inboxes | Powered by JetHome®