[redhat-lspp] labeled ipsec status
Paul Moore
paul.moore at hp.com
Mon Jan 8 20:45:25 UTC 2007
On Monday, January 8 2007 3:31 pm, Eric Paris wrote:
> > 3. Toggle to accept or reject unlabeled packets.
> > Dan has completed this. He added a boolean, allow_unlabeled_packets,
> > to selinux policy. Currently, because of a problem in lspp60
> > kernel, boolean does not work. I tested the boolean on
> > upstream kernel from kernel.org, 2.6.20-rc3-git4 and the boolean
> > worked great and as expected. (See #5 below as to why
> > it did not work in lspp60.)
>
> can paul make sure this works for NetLabel as well (since 5 shouldn't be
> applicable to NetLabel)?
I'll verify that this still works on lspp.60 but I have no reason to believe
it wouldn't. The way NetLabel allows/denies non-NetLabel packets is
different from IPsec.
When SELinux receives a packet it queries NetLabel to see if there are any
NetLabel related security attributes attached to the packet; there are three
possible results from this query:
1. security attributes are present - query function returns success populates
a structure with the NetLabel security attributes
2. security attributes are not present and the unlabeled flag is set to
allow - query function returns success and the security attribute structure
is cleared
3. security attributes are not present and the unlabeled flag is set to deny -
query function returns failure
We can go into all the pros/cons of such an approach vs a granular policy
approach if you would like but when I lost the argument to use
SECINITSID_NETMSG as the default NetLabel packet type we lost the ability to
distinguish between NetLabel'd and non-NetLabel'd packets in SELinux policy
(NetLabel uses SECINITSID_UNLABELED/unlabeled_t for incoming traffic).
--
paul moore
linux security @ hp
More information about the redhat-lspp
mailing list