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 22:42:45 +0100
From:	Samir Bellabes <sam@...ack.fr>
To:	Paul Moore <paul.moore@...com>
Cc:	Jan Engelhardt <jengelh@...ozas.de>,
	Stephan Peijnik <stephan@...jnik.at>,
	"linux-security-module" <linux-security-module@...r.kernel.org>,
	netdev@...r.kernel.org,
	Netfilter Developer Mailing List 
	<netfilter-devel@...r.kernel.org>
Subject: Re: RFC: Mandatory Access Control for sockets aka "personal firewalls"

Paul Moore <paul.moore@...com> writes:

> However, in dealing with the issue of personal firewalls I think the 
> biggest issue will be the user interaction as you described ... how do 
> you explain to a user who clicked the "allow" button that the system 
> rejected their traffic?

maybe because the personnal firewall is the only one which deal with the
LSM hook related to network (?)

>> >But what you are asking is to have multiple security models at the
>> > same time, with some kind of priority.
>> >I don't know if it's ok or not, but what I'm sure is that snet will
>> > use LSM hooks or your new framework without any problems in fact,
>> > as you are going to make some kind of wrapper on the members of the
>> > struct security_operations.
>>
>> jan>>> 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.
>> >
>> >Indeed I thought about that when writing snet.
>>
>> For starters, the existing LSM interface and the LSM  modules
>> themselves could be split up so as to provide
>>
>>  selinux.ko
>>   \_ selinux_net.ko
>>   \_ selinux_fs.ko
>>   ...
>>
>> just a suggestion to ease the thinking process for now.
>> If a purely network-related LSM does not have to think about
>> "do I need to implement FS hooks that do chaining or not..."
>> it is a lot better off.
>
> Unfortunately I don't think this solves the problem, it just changes it 
> slightly.  It is no longer "How do I enable SELinux and XXX personal 
> firewall?" but instead "How do I enable SELinux's network access 
> controls and XXX personal firewall?"

And introduce another one : "how do I make SElinux's network access
controls and Apparmor filesystem access controls working together ?"
this is the true deal in this kind of solution.

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