Bug 1119662
| Summary: | BUG: NetLabel lead to kernel panic on some SELinux levels | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Vit Ry <Frodox> | ||||||||||||
| Component: | kernel | Assignee: | Paul Moore <pmoore> | ||||||||||||
| kernel sub component: | SELinux | QA Contact: | Xin Long <lxin> | ||||||||||||
| Status: | CLOSED ERRATA | Docs Contact: | |||||||||||||
| Severity: | unspecified | ||||||||||||||
| Priority: | unspecified | CC: | Frodox, lilu, lxin, pmatouse, ypei, zshi | ||||||||||||
| Version: | 7.0 | Keywords: | SELinux | ||||||||||||
| Target Milestone: | rc | ||||||||||||||
| Target Release: | --- | ||||||||||||||
| Hardware: | x86_64 | ||||||||||||||
| OS: | Linux | ||||||||||||||
| Whiteboard: | |||||||||||||||
| Fixed In Version: | kernel-3.10.0-183.el7 | Doc Type: | Bug Fix | ||||||||||||
| Doc Text: | Story Points: | --- | |||||||||||||
| Clone Of: | |||||||||||||||
| : | 1130197 (view as bug list) | Environment: | |||||||||||||
| Last Closed: | 2015-03-05 12:29:50 UTC | Type: | Bug | ||||||||||||
| Regression: | --- | Mount Type: | --- | ||||||||||||
| Documentation: | --- | CRM: | |||||||||||||
| Verified Versions: | Category: | --- | |||||||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||||||
| Embargoed: | |||||||||||||||
| Bug Depends On: | |||||||||||||||
| Bug Blocks: | 1130197 | ||||||||||||||
| Attachments: |
|
||||||||||||||
Confirming that I've been able to reproduce this problem on kernel-3.10.0-131.el7.x86_64 using the instructions above. I've identified at least one problem: the NetLabel secattr catmap functions not correctly setting bits if the new bit is less than the starting bit of the first structure instance. There may be more problems as well, but this is perhaps the most significant. (In reply to Paul Moore from comment #3) > I've identified at least one problem: the NetLabel secattr catmap functions > not correctly setting bits if the new bit is less than the starting bit of > the first structure instance. Yup. Also, due to Cipso RFC 3.4.4.5 [1] "The ranges MUST be non-overlapping and be listed in *descending* order." It looks like the logic is wrong, if we meet, say, c900, then c500 and then c100, because we will stop on the wrong block. Maybe my patch[2] will help you to find all issues. [1]: https://www.kernel.org/doc/Documentation/netlabel/draft-ietf-cipso-ipsecurity-01.txt [2]: https://gist.github.com/Frodox/86e489f4e8d791cbe327 I've already fixed the problem with the catmap correctly setting bits below the first starting bit, but there are some other issues that need to be corrected as well. Created attachment 923017 [details]
01-netlbl-catmap_fix.patch
Created attachment 923018 [details]
02-netlbl-catmap_ulong_fixes.patch
Created attachment 923019 [details]
03-netlbl-catmap_walk_fix.patch
Created attachment 923020 [details]
04-netlbl-catmap_rename.patch
The attached four patches should resolve the problem reported by the original reporter as well as a number of other issues found in the course of fixing this problem. However, I should note that these patches have only gone through the most basic of testing and therefore are not yet suitable for submission upstream or inclusion in RHEL7. I'm posting them here in case anyone is interested in the problem and wanted to help test a potential solution. Finally, these patches are based against Linux v3.15 and not the RHEL7 kernel so there will be some backporting needed. Also, patch #4 is not strictly necessary but I will be including it in the patchset I publish upstream so I've included here for reference. Upstream patchset posting: * http://marc.info/?l=selinux&m=140684327318705&w=2 * http://marc.info/?l=selinux&m=140684354618779&w=2 * http://marc.info/?l=selinux&m=140684374218827&w=2 * http://marc.info/?l=selinux&m=140684397518921&w=2 * http://marc.info/?l=selinux&m=140684419119025&w=2 FYI, I've merged this into the SELinux tree for 3.17 and sent another pull request. As soon as the tree is (re)pulled into the linux-security tree I'll update this BZ and start backporting. Patch(es) available on kernel-3.10.0-183.el7 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHSA-2015-0290.html |
Created attachment 918084 [details] [1] kernel panic. Bottom of the panic screen # Description of problem: While using network with configured Netlabel it may lead to kernel panic on some SELinux levels. # Version-Release number of selected component (if applicable): netlabel_tools-0.19-7.el6.x86_64.rpm kernel: Linux rhel7 3.10.0-123.el7.x86_64 Also I reproduced it on RHEL 6.3/7.0, CentOs 6.5/7.0, Fedora 20. That is what I have been tested. I think it can be reproduced on older versions/kernels too. # How reproducible: # Steps to Reproduce: 1. Setup NetLabel. [Assume that 192.168.56.* --- local network (VBox HostOnly, for example) ] # netlabelctl cipsov4 add pass doi:1 tags:5 # netlabelctl map del default # netlabelctl map add default address:0.0.0.0/0 protocol:unlbl # netlabelctl map add default address:192.168.56.101/16 protocol:cipsov4,1 2. Give some user selinux range s0:c0.c1023. selevel not so important. All the matter in categories ... # semanage user -mr s0-s0:c0.c1023 user_u # semanage login -s user_u -mr s0-s0:c0.c1023 myuser1 # setenforce 1 (just in case) 3. Login with `myuser1`, change selinux level and ping someone in your local network login: myuser1 password: ... $ newrole -l s0:c255,c800 Password ... $ ping 192.168.56.1 (some another PC) # Actual results: It will lead to kernel panic. See screenshot 1. If not, exit and try with another level (see Additional info). # Expected results: Receive ping reply (marked one, due to NetLabel configured). # Additional info: RHEL fails with all of this levels: 1. s0:c255,c800 2. s0:c350,c800 3. s0:c500,c800 4. s0:c255,c513 5. s0:c500,c513 6. s0:c511,c513 7. s0:c510,c512 8. ... (I think, there are more of them) CentOs and Fedora sometimes fails not with first, but with second or third one. --- I used kdump to debug this crash and it looks like there are problems in netlbl_secattr_catmap_setrng() and netlbl_secattr_catmap_setbit() function, because of "BUG: unablle to handle kernel paging request at ... from netlbl_secattr_catmap_setbit" (from logs).