netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Patrick McHardy <kaber@trash.net>
To: James Morris <jmorris@namei.org>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	netdev@vger.kernel.org, "David S. Miller" <davem@davemloft.net>,
	linux-security-module@vger.kernel.org,
	netfilter-devel@lists.netfilter.org,
	Stephen Smalley <sds@tycho.nsa.gov>
Subject: Re: [PATCH net-2.6.25] Add packet filtering based on process's security context.
Date: Mon, 03 Dec 2007 08:58:59 +0100	[thread overview]
Message-ID: <4753B743.2090501@trash.net> (raw)
In-Reply-To: <Xine.LNX.4.64.0711231005270.4252@us.intercode.com.au>

James Morris wrote:
> On Thu, 22 Nov 2007, Tetsuo Handa wrote:
> 
>> This patch allows LSM modules filter incoming connections/datagrams
>> based on the process's security context who is attempting to pick up.
>>
>> There are already hooks to filter incoming connections/datagrams
>> based on the socket's security context, but these hooks are not
>> applicable when one wants to do TCP Wrapper-like filtering
>> (e.g. App1 is permitted to accept TCP connections from 192.168.0.0/16).
> 
> This functionality looks like it could be useful in that we currently have 
> no direct security mapping from incoming packet to user process, but only 
> to the receiving socket, as you mention.  For SELinux, it may help us 
> simplify/clarify policy.
> 
> It's also been long-desired for netfilter/iptables, to allow ipt_owner to 
> work cleanly for incoming packets.
> 
> So, this probably needs to be implemented in a way which works for both LSM 
> and netfilter.  There have been several discussions on the issue from the 
> netfilter side, although I don't know what the latest status of that is 
> (I've expanded the cc list to hopefully get some more feedback).

No news on that. I'm also a bit sceptical if adding all this complexity
and overhead would really be worth it (considering only netfilter) just
to use the owner match and UID/GID matching. It wouldn't even be
accurate because there is not 1:1 mapping of sockets and processes.

I actually like Samir Bellabes' approach, which doesn't suffer from
these problems IIRC.

>>From memory, one approach under discussion was to add netfilter hooks to 
> the transport layer, which could be invoked correctly by each type of 
> protocol when the target process is selected.

We can only invoke the hooks after the socket lookup, but we don't
know which process is going to call recvmsg() for that socket.

  parent reply	other threads:[~2007-12-03  7:59 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-21 12:30 [PATCH] Add packet filtering based on process's security context Tetsuo Handa
2007-11-22 13:35 ` [PATCH net-2.6.25] " Tetsuo Handa
2007-11-22 23:29   ` James Morris
2007-11-24  2:14     ` [PATCH net-2.6.25] Add packet filtering based on process'ssecurity context Tetsuo Handa
2007-11-29  4:57       ` Samir Bellabes
2007-11-30 14:07         ` Tetsuo Handa
2007-11-30 14:29           ` Samir Bellabes
2007-11-30 14:59             ` Tetsuo Handa
2007-11-30 16:07               ` Samir Bellabes
2007-12-01  3:48                 ` Tetsuo Handa
2007-12-01  7:18                   ` Samir Bellabes
     [not found]                     ` <200712011715.JFJ39500.QOJFStHFMOOLVF@I-love.SAKURA.ne.jp>
     [not found]                       ` <200712021224.CBH90604.HMtJFFOOFLQVSO@I-love.SAKURA.ne.jp>
     [not found]                         ` <m28x4a1vy8.fsf@synack.fr>
     [not found]                           ` <200712042200.CDH65164.OOFSMFFLHJOtVQ@I-love.SAKURA.ne.jp>
2007-12-09  8:06                             ` Tetsuo Handa
2007-12-09 16:05                               ` Samir Bellabes
2007-12-03  7:58     ` Patrick McHardy [this message]
2007-12-03 13:17       ` [PATCH net-2.6.25] Add packet filtering based on process's securitycontext Tetsuo Handa
  -- strict thread matches above, loose matches on Subject: below --
2007-12-31  6:21 [PATCH net-2.6.25] Add packet filtering based on process's security context Tetsuo Handa
2008-01-22 15:16 Tetsuo Handa
2008-01-22 16:49 ` Casey Schaufler
2008-01-23  1:26   ` [PATCH net-2.6.25] Add packet filtering based on process\'s " Tetsuo Handa
2008-01-24 11:47 ` [PATCH net-2.6.25] Add packet filtering based on process's " Tetsuo Handa
2008-01-24 15:03   ` Paul Moore

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=4753B743.2090501@trash.net \
    --to=kaber@trash.net \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=jmorris@namei.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=netfilter-devel@lists.netfilter.org \
    --cc=penguin-kernel@I-love.SAKURA.ne.jp \
    --cc=sds@tycho.nsa.gov \
    /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;
as well as URLs for NNTP newsgroup(s).