netdev - Re: RFC: Mandatory Access Control for sockets aka "personal firewalls"

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:	Tue, 20 Jan 2009 19:56:20 +0100
From:	Stephan Peijnik <stephan@...jnik.at>
To:	Jan Engelhardt <jengelh@...ozas.de>
Cc:	linux-security-module <linux-security-module@...r.kernel.org>,
	netdev@...r.kernel.org,
	Netfilter Developer Mailing List 
	<netfilter-devel@...r.kernel.org>, sam@...ack.fr
Subject: Re: RFC: Mandatory Access Control for sockets aka "personal
	firewalls"

On Tue, 2009-01-20 at 19:24 +0100, Jan Engelhardt wrote:
> On Tuesday 2009-01-20 18:48, Stephan Peijnik wrote:
> >
> >A personal firewall should implement per-application mandatory access
> >control for sockets. In short this means that such a program decides
> >every time a call to either socket(), accept(), bind(), connect() or
> >listen()[...]
> 
> Without reading any further (yet), that sounds like
> http://www.synack.fr/project/cn_net/cn_net.html

Yes, it does, and it's exactly that. However, as a LSM it can only be
used whilst no other LSM is enabled. 
Samir Bellabes has been involved in the discussion at
linux-security-module too.
Even though I like the implementation personally I'm unsure about
whether this should be dubbed "the one" way to do this or whether there
should be an API for alternative implementations.

> >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.
> >On the other hand this would add, besides the LSM calls that are in
> >place in net/socket.c a few extra calls which might not be what we want.[...]
> 
> My opinion up to here would be to split LSM into the LSM category
> {selinux, apparmor, tomoyo} and the other, new LSM category
> {networking stuff}, just as a potential idea to get over the
> stacking / single LSM use  issue.

The problem here is that all of your three examples do use the LSM
networking hooks too. If two functions are to be called from the LSM
core (ie. the generic LSM one and the networking-LSM one) we get pretty
much the same problem back as if we multiple generic LSMs enabled.

> >Implementations using the LSM approach are TuxGuardian [0] and snet [1].
> >Code implementing the last mentioned approach can be found in git over
> >at [2] in the sactl-direct branch.
> >
> >[0] http://tuxguardian.sourceforge.net/
> 
> tuxguardian is probably regardable as obsoleted by cn_net (if it's
> finished someday, or is it?) -- Samir probably knows more.

The tuxguardian developers seem to be interested in picking up
development again and as I wrote Samir has already been involved in this
discussion.

-- Stephan

--
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