Paul Moore <paul.moore@xxxxxx> 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 netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
