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

quoted text
> 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 (?)

quoted text
>> >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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html