netdev - Re: Real networking namespace

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 09 Oct 2009 12:44:52 -0400
From:	Stephen Smalley <sds@...ho.nsa.gov>
To:	Stephen Hemminger <shemminger@...ux-foundation.org>
Cc:	linux-security-module@...r.kernel.org,
	Al Viro <viro@...IV.linux.org.uk>, netdev@...r.kernel.org,
	Paul Moore <paul.moore@...com>,
	James Morris <jmorris@...ei.org>
Subject: Re: Real networking namespace

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)
> >   * 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.
> > 
> > Since one of the first rules of security is "don't reinvent", surely
> > others have dealt with this issue. Any good ideas?
> 
> 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

-- 
Stephen Smalley
National Security Agency

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html