netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paul Moore <paul.moore@hp.com>
To: Stephan Peijnik <stephan@peijnik.at>
Cc: "linux-security-module" <linux-security-module@vger.kernel.org>,
	netdev@vger.kernel.org, netfilter-devel@vger.kernel.org
Subject: Re: RFC: Mandatory Access Control for sockets aka "personal firewalls"
Date: Tue, 20 Jan 2009 15:47:44 -0500	[thread overview]
Message-ID: <200901201547.44981.paul.moore@hp.com> (raw)
In-Reply-To: <1232473719.24943.102.camel@sp-laptop3.sp-local>

On Tuesday 20 January 2009 12:48:39 pm Stephan Peijnik wrote:
> All proposed implementations of personal firewalls until now have
> made it rather clear that the decision-making logic should be placed
> in userspace, whilst only a small piece of code communicating with a
> userspace daemon should be placed in the kernel itself.
>
> Okay, enough of the (not so) brief description on what people want to
> do and on to a summary of what has been discussed so far.
>
> Most implementations started out using the LSM framework for creating
> a personal firewall, that's also the reason the whole discussion
> started out on the LSM mailing list.
> Even though this looks like a good solution there is one main problem
> with the LSM framework right now: only a single LSM module can be
> loaded and enabled at a time.

...

> Another approach that has been suggested is using the netfilter
> framework for this purpose. Even though this again sounds like a good
> idea in the first place it also has its flaws.

...

> And yet another approach was suggested: hooking socket-related calls
> directly in net/socket.c. This would mean that the personal firewall
> code is called directly from net/socket.c and can this way work in
> process-context, without using the LSM framework.

Another option that was brought up (although perhaps not very clearly 
since it isn't listed here) was the embedding of the personal firewall 
hooks into the individual LSMs roughly similar to how capabilities are 
handled with SELinux today (a separate security mechanism that has 
explicit calls within SELinux).  This approach enables the use of 
current LSMs (although minor modifications will be needed) and avoids 
the need to add new hooks to the core network stack.

> What has not been agreed on yet is whether only a way of hooking
> these calls should be made available to implementations or whether
> the whole in-kernel part should be developed together and allow
> implementations of personal firewalls in userspace only, for example
> using a netlink socket to communicate with the shared in-kernel code.

Since there will always be a significant userspace component to any 
personal firewall approach it seems reasonable to push the decision 
making into userspace and leave the kernel component relatively simple.  
The basic idea behind Samir's "snet" concept where the kernel simply 
passes messages to userspace and waits for a verdict seems like a 
reasonable approach in that it can be made to support different 
personal firewall implementations/designs without significant changes 
to the kernel.

-- 
paul moore
linux @ hp

  parent reply	other threads:[~2009-01-20 20:48 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-20 17:48 RFC: Mandatory Access Control for sockets aka "personal firewalls" Stephan Peijnik
2009-01-20 18:24 ` Jan Engelhardt
2009-01-20 18:56   ` Stephan Peijnik
2009-01-20 20:15     ` Samir Bellabes
2009-01-20 20:31       ` Jan Engelhardt
2009-01-20 20:53         ` Paul Moore
2009-01-20 21:42           ` Samir Bellabes
2009-01-20 21:51             ` Paul Moore
2009-01-20 19:46 ` Jonathan Day
2009-01-20 21:01   ` Paul Moore
2009-01-21  0:54   ` Samir Bellabes
2009-01-21  1:18     ` Casey Schaufler
2009-01-21  3:14       ` Samir Bellabes
2009-01-20 20:47 ` Paul Moore [this message]
2009-01-20 23:48   ` Stephan Peijnik
2009-01-21  8:18     ` Samir Bellabes
2009-01-21 14:49     ` Paul Moore
2009-01-21  0:40 ` Samir Bellabes
  -- strict thread matches above, loose matches on Subject: below --
2009-01-21  7:25 Rob Meijer
2009-01-21  8:15 ` Peter Dolding
2009-01-21  8:35   ` Jan Engelhardt
2009-01-21  9:32 Rob Meijer
2009-01-21 23:28 ` Peter Dolding
2009-01-22  0:50   ` Jonathan Day
2009-01-22  0:59     ` Casey Schaufler
2009-01-22  6:29       ` Jonathan Day
2009-01-22 13:46     ` Peter Dolding
2009-01-22 17:08       ` Jonathan Day

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=200901201547.44981.paul.moore@hp.com \
    --to=paul.moore@hp.com \
    --cc=linux-security-module@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=stephan@peijnik.at \
    /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).