Bug 230255 - LSPP: cipso mapping settings prevents login into system
LSPP: cipso mapping settings prevents login into system
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
5.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Eric Paris
Brian Brock
: OtherQA
Depends On:
Blocks: RHEL5LSPPCertTracker
  Show dependency treegraph
 
Reported: 2007-02-27 15:05 EST by Loulwa Salem
Modified: 2010-10-22 09:23 EDT (History)
6 users (show)

See Also:
Fixed In Version: RHBA-2007-0959
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-11-07 14:42:05 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch to kernel-2.6.18-8.el5.lspp.67 (1.56 KB, patch)
2007-02-28 10:09 EST, Paul Moore
no flags Details | Diff

  None (edit)
Description Loulwa Salem 2007-02-27 15:05:02 EST
Description of problem:
When cipso mappings are in effect, a user is not allowed to log in into a 
system (even from localhost). The connection just sits there until terminated.

Version-Release number of selected component (if applicable):
I am running with lspp.65 kernel currently, but also tried .64 and .63 kernels 
and I see the problem still. I saw this on both ppc and x86_64

How reproducible: Always


Steps to Reproduce:
1. 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

2. 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
  
Actual results:
connection just hangs


Expected results:
connection should succeed and a password prompt should display

Additional info:
[root/abat_r/SystemLow@joy-hv4 ~]# rpm -qa | grep selinux-policy
selinux-policy-2.4.6-38.el5
selinux-policy-targeted-2.4.6-38.el5
selinux-policy-strict-2.4.6-38.el5
selinux-policy-mls-2.4.6-38.el5
selinux-policy-devel-2.4.6-38.el5
[root/abat_r/SystemLow@joy-hv4 ~]# rpm -qa | grep netlabel
netlabel_tools-0.17-9.el5

I captured the following tcpdump while trying the ssh command ...
[root/abat_r/SystemLow@joy-hv4 framework]# tcpdump -vv -i lo
tcpdump: listening on lo, link-type EN10MB (Ethernet), capture size 96 bytes
13:36:05.473874 IP (tos 0x0, ttl  64, id 20931, offset 0, flags [DF], proto: 
TCP (6), length: 72, options ( unknown (134) len 10EOL (0) len 1 )) 
localhost.localdomain.58117 > localhost.localdomain.ssh: S, cksum 0x2c1a 
(correct), 3261345366:3261345366(0) win 32792 <mss 16396,sackOK,timestamp 
268926869 0,nop,wscale 7>
13:36:05.474246 IP (tos 0xc0, ttl  64, id 52022, offset 0, flags [none], 
proto: ICMP (1), length: 112, options ( unknown (134) len 10EOL (0) len 1 )) 
localhost.localdomain > localhost.localdomain: ICMP parameter problem - octet 
29, length 80
        IP (tos 0x0, ttl  64, id 20931, offset 0, flags [DF], proto: TCP (6), 
length: 72, options ( unknown (134) len 10EOL (0) len 1 )) 
localhost.localdomain.58117 > localhost.localdomain.ssh:  tcp 40 [bad hdr 
length 0 - too short, < 20]

2 packets captured
6 packets received by filter
0 packets dropped by kernel
Comment 1 Paul Moore 2007-02-27 19:06:16 EST
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).
Comment 2 Loulwa Salem 2007-02-27 19:30:51 EST
Thanks Paul .. that makes sense, I'm gonna try a few things to make sure this 
is how it behaves correctly now that I saw your explanation .. 

Having the ICMP error packets is what confused me .. but that should be fixed 
per the other bug you mentioned.
I guess the fact that it worked before was the bug and it is fixed now .. I'll 
do few tests and close this bug if all seems normal.
Comment 3 Paul Moore 2007-02-27 21:50:11 EST
Okay, thanks for the help testing.  I did some quick testing after I realized 
what the problem was and everything looked fine to me.
Comment 4 Eric Paris 2007-02-27 23:25:31 EST
I believed that the patch for 221648 was already in the GA kernel (and thus the
LSPP chain)  are you saying that something about that patch in the LSPP kernel
is not working?
Comment 5 Paul Moore 2007-02-28 07:58:30 EST
My mistake, based on the BZ it does appear that it should be in the recent 
kernels.  I'll verify that the patch is in the latest lspp.* kernel and try to 
figure out why the packets are being sent.  I will update this entry when I 
know more.
Comment 6 Paul Moore 2007-02-28 10:09:37 EST
Created attachment 148924 [details]
Patch to kernel-2.6.18-8.el5.lspp.67

This patch should resolve the problem of the packets being sent when there is
not a valid sensitivity level mapping.	I have only done some simple tests so
far but it does appear to solve the problem.  I will continue to test this
patch and prepare it for upstreaming against the current net-2.6 tree and the
latest stable tree.

See the patch and the patch header for an explanation of the problem.
Comment 7 Paul Moore 2007-02-28 15:08:18 EST
This patch has now been posted upstream:

* http://marc.theaimsgroup.com/?l=linux-netdev&m=117269309023961&w=2
Comment 8 Paul Moore 2007-03-12 17:14:18 EDT
I have verified that this bug does appear to be fixed in 
kernel-2.6.18-8.1.1.el5.lspp.68.
Comment 9 Loulwa Salem 2007-04-03 17:05:36 EDT
I just verified this against the .71 kernel as well. Now I get permission 
denied (as expected according to the patch, returning EPERM). And ofcourse I 
don't see any traffic on the local interface.

Can this bug be closed?
Comment 10 Paul Moore 2007-04-03 17:38:08 EDT
Fine with me.
Comment 11 Eric Paris 2007-04-03 17:44:10 EDT
Bug will remain open until it is committed into RHEL 5.1 CVS tree and verified
as fixed by the RHEL QA team for release in our 5.1 offering.   So really for
everyone outside Red Hat just ignore this bug from now on.
Comment 14 Don Zickus 2007-06-15 20:35:35 EDT
in 2.6.18-27.el5
You can download this test kernel from http://people.redhat.com/dzickus/el5
Comment 16 John Poelstra 2007-08-27 14:41:41 EDT
A fix for this issue should have been included in the packages contained in the
RHEL5.1-Snapshot3 on partners.redhat.com.  

Requested action: Please verify that your issue is fixed as soon as possible to
ensure that it is included in this update release.

After you (Red Hat Partner) have verified that this issue has been addressed,
please perform the following:
1) Change the *status* of this bug to VERIFIED.
2) Add *keyword* of PartnerVerified (leaving the existing keywords unmodified)

If this issue is not fixed, please add a comment describing the most recent
symptoms of the problem you are having and change the status of the bug to FAILS_QA.

More assistance: If you cannot access bugzilla, please reply with a message to
Issue Tracker and I will change the status for you.  If you need assistance
accessing ftp://partners.redhat.com, please contact your Partner Manager.
Comment 17 John Poelstra 2007-08-30 20:27:41 EDT
A fix for this issue should have been included in the packages contained in the
RHEL5.1-Snapshot4 on partners.redhat.com.  

Requested action: Please verify that your issue is fixed *as soon as possible*
to ensure that it is included in this update release.

After you (Red Hat Partner) have verified that this issue has been addressed,
please perform the following:
1) Change the *status* of this bug to VERIFIED.
2) Add *keyword* of PartnerVerified (leaving the existing keywords unmodified)

If this issue is not fixed, please add a comment describing the most recent
symptoms of the problem you are having and change the status of the bug to FAILS_QA.

If you cannot access bugzilla, please reply with a message to Issue Tracker and
I will change the status for you.  If you need assistance accessing
ftp://partners.redhat.com, please contact your Partner Manager.
Comment 19 errata-xmlrpc 2007-11-07 14:42:05 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2007-0959.html

Note You need to log in before you can comment on or make changes to this bug.