All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Moore <paul.moore@hp.com>
To: Stephen Smalley <sds@tycho.nsa.gov>
Cc: Stephen Hemminger <shemminger@linux-foundation.org>,
	linux-security-module@vger.kernel.org,
	Al Viro <viro@zeniv.linux.org.uk>,
	netdev@vger.kernel.org, James Morris <jmorris@namei.org>
Subject: Re: Real networking namespace
Date: Fri, 9 Oct 2009 18:12:15 -0400	[thread overview]
Message-ID: <200910091812.16046.paul.moore@hp.com> (raw)
In-Reply-To: <1255106692.2182.224.camel@moss-pluto.epoch.ncsc.mil>

On Friday 09 October 2009 12:44:52 pm Stephen Smalley wrote:
> On Fri, 2009-10-09 at 12:37 -0400, Stephen Smalley wrote:
> > On Fri, 2009-10-09 at 08:38 -0700, Stephen Hemminger wrote:
> > > The existing networking namespace model is unattractive for what I
> > > want, has anyone investigated better alternatives?
> > >
> > > I would like to be able to allow access to a network interface and
> > > associated objects (routing tables etc), to be controlled by Mandatory
> > > Access Control API's. I.e grant access to eth0 and to only certain
> > > processes.  Some the issues with the existing models are:
> > >   * eth0 and associated objects don't really exist in filesystem so
> > >     not subject to LSM style control (SeLinux/SMACK/TOMOYO)

As Stephen points out, SELinux does have the ability to assign security labels 
to network interfaces, check out the 'semanage' command.  A while back I wrote 
up something about the SELinux network "ingress/egress" access controls:

 * http://paulmoore.livejournal.com/2128.html

Smack doesn't support controlling network access at the interface level, but 
that is due to a Smack design decision and not an inherent functionality gap 
in the LSM.  TOMOYO is currently working on improved network access controls 
(see patches posted earlier this week), I haven't had a chance to review them 
yet so I don't know the state of TOMOYO's network access controls.

> > >   * network namespaces do not allow object to exist in multiple
> > > namespaces. The current model is more restrictive than chroot jails. At
> > > least with chroot, put filesystem objects in multiple jails.

Perhaps I don't fully understand what you are getting at here, but I don't 
think this should be an issue with a flexible LSM.

> > Is there something that prevents you from using the existing SELinux
> > network access controls?  netif is a security class governed by SELinux
> > policy, and routing table operations would be covered by the SELinux
> > checks on netlink_route_socket.  SELinux uses a combination of LSM hooks
> > and netfilter hooks to mediate network operations.
> 
> Also, depending on what you want to do, SECMARK may be useful to you.
> That allows you to mark packets with security contexts via iptables, and
> then use SELinux policy to control their flow.
> http://paulmoore.livejournal.com/4281.html
> http://james-morris.livejournal.com/11010.html

While we're at it, a few more links ... here is a presentation from last year 
on Linux's labeled networking capabilities (which hits at a lot of your 
questions):

 * http://paulmoore.livejournal.com/964.html

... and there is a video too:

 * http://paulmoore.livejournal.com/1329.html

-- 
paul moore
linux @ hp

  reply	other threads:[~2009-10-09 22:12 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-09 15:38 Real networking namespace Stephen Hemminger
2009-10-09 16:37 ` Stephen Smalley
2009-10-09 16:44   ` Stephen Smalley
2009-10-09 22:12     ` Paul Moore [this message]
2009-10-10  2:08       ` Stephen Hemminger
2009-10-10 21:40         ` Paul Moore
2009-10-10 18:14       ` Casey Schaufler

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=200910091812.16046.paul.moore@hp.com \
    --to=paul.moore@hp.com \
    --cc=jmorris@namei.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=sds@tycho.nsa.gov \
    --cc=shemminger@linux-foundation.org \
    --cc=viro@zeniv.linux.org.uk \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.