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
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).
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.
Okay, thanks for the help testing. I did some quick testing after I realized what the problem was and everything looked fine to me.
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?
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.
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.
This patch has now been posted upstream: * http://marc.theaimsgroup.com/?l=linux-netdev&m=117269309023961&w=2
I have verified that this bug does appear to be fixed in kernel-2.6.18-8.1.1.el5.lspp.68.
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?
Fine with me.
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.
in 2.6.18-27.el5 You can download this test kernel from http://people.redhat.com/dzickus/el5
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.
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.
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