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-next>] [day] [month] [year] [list]

Date:	Wed, 21 Jan 2009 08:25:29 +0100 (CET)
From:	"Rob Meijer" <capibara@...all.nl>
To:	"Casey Schaufler" <casey@...aufler-ca.com>
Cc:	"Samir Bellabes" <sam@...ack.fr>, imipak@...oo.com,
	"linux-security-module" <linux-security-module@...r.kernel.org>,
	"Stephan Peijnik" <stephan@...jnik.at>, netdev@...r.kernel.org,
	netfilter-devel@...r.kernel.org
Subject: Re: RFC: Mandatory Access Control for sockets aka "personal 
     firewalls"

On Wed, January 21, 2009 02:18, Casey Schaufler wrote:
>
>> we don't need this at all, as we are in process context, syscall can
>> sleep.
>> Trust me, it's strange to have it's web browser freezing waiting for a
>> timeout if the userspace part doesn't reply, but if it's replying, it's
>> transparent.
>
> I hate to be the one to say this, but it looks to me as if the
> easiest way to solve the problems that you have outlined would
> be to create a new LSM based on SELinux with two important
> changes. The first would be to have a separate policy for each
> user (or process tree) and the second would be to make the policy
> specification discretionary. SELinux has all the mechanism you're
> talking about, but you want the policy being enforced to reflect
> a set of "personal firewall" rules rather than "domain type" rules.
>  From the lobby at LCA in Hobart these rule sets are pretty hard to
> tell apart. And let's not have the "SELinux isn't designed to do
> that" row. Of course it isn't. Nonetheless, the personal firewall
> sure sounds a lot like SELinux if you ignore the MAC/DAC difference.

I think this is a perfect example of where using MAC 'and' DAC or rather
centrally 'and' user managed profiles would be very fruitful. If you can
create a purely permissive centrally managed per user profile, in fact
delegating a permission set and allow each user to decompose and
discretionary delegate parts of this profile to programs run by this same
user, but with MAC restrictions when delegating to a process run by a
different user, you would IMHO have a very powerful combination of MAC and
DAC.

I'm not sure however a label based MAC system would be best suited for
combining MAC and DAC in such a way.



Rob

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