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 -- redhat-lspp mailing list [email protected] https://www.redhat.com/mailman/listinfo/redhat-lspp
