[redhat-lspp] Re: 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.

Something odd is happening as based on the packet dump the CIPSO option is 10 
bytes long, which for tag type 1 would indicate a lack of categories yet you 
are using "c2" which should map to CIPSO category "1" based on your DOI 
settings.  To further complicate things, assuming I've done my quick math 
correctly the ICMP parameter error is pointing at the CIPSO length field in 
the tag.  It's hard to say for certain at this point, but it kinda looks like 
the packet is not being created correctly.

Please retry with the following CIPSO DOI configuration:

 # netlabelctl cipsov4 add pass doi:1 tags:1

> In the past this test used to pass.. so I was wondering if this is an
> intended change, or something is not working.

Which was the latest kernel which worked correctly?

-- 
paul moore
linux security @ hp