[redhat-lspp] different cipso mapping behavior

[Paul Moore]

On Monday, February 26 2007 7:17:19 pm Loulwa Salem wrote:
> Hi Paul,
> After the meeting, I went back to try some cipso tests and noticed the
> following behavior that didn't use to happen before ..
> I am on the latest RHEL drop with the .65 kernel, latest policy .38, and
> netlabel_tools-0.17-9.el5
>
> I was trying to test the cipso mappings and that a connection is
> granted/denied correctly between two systems when mappings are in place.
>
> Here is what I had a problem with ..
>
> I set up a system with following rules
>   netlabelctl cipsov4 add std doi:1 tags:1 levels:2=1 categories:2=1
>   netlabelctl map del default
>   netlabelctl map add default protocol:cipsov4,1
>
> Now I try to log in (note I already have a session on the system and I use
> that one to log in, so its coming through localhost)
>   ssh -l testuser/user_r/s2:c2-s2:c2 localhost
>
> The above command hangs .. Looking at the output of tcpdump (tcpdump -v -i
> lo) I see an ICMP error (output at end of this message). I also checked,
> and there were no relevant audit records or anything useful in
> /var/log/messages or /var/log/secure.

For those of you not following the RHEL BZ entry for this problem:

***
I should have seen this sooner, but I was thrown off by the "ssh -l 
testuser/user_r/s2:c2-s2:c2 localhost" command line syntax ... this is not a 
bug, this is the correct behavior.

By configuring a "std" CIPSO DOI with a _only_ level mapping of "2=1" that 
CIPSO DOI will only allow traffic to be sent when the domain sending the 
packet has an effective sensitivity level of "s2".  The reason for this is 
that the CIPSO DOI only has a valid level mapping for "s2".  The same logic 
applies to categories.  If you were to try to run any network application 
using the default effective sensitivity label of "s0" then you should not be 
able to generate network traffic because you have not defined a valid 
sensitivity label mapping.

The fact that network traffic was generated at all (see the packet trace) 
instead of the socket failing to be created is a side effect of a known bug 
which has already been patched in the 2.6.19-stable kernels and 2.6.20.  
Another BZ was entered on January 5th, 2007 to track this other problem (BZ 
#221648).
***

-- 
paul moore
linux security @ hp