Description of problem: I noticed an error message when I was booting my mls system. I get this message: error: "Operation not permitted" reading key "kernel.cap-bound" I tracked it down to the network init.d script which then runs /etc/sysconfig/network-scripts/network-functions-ipv6 which runs 'sysctl -a', which generates the error. I don't get the error in permissive mode, but there are no avc messages. Version-Release number of selected component (if applicable): RHEL5 Beta 2 with mls policy and related packages from Dan's people page. Also running the .57 lspp kernel. How reproducible: very Steps to Reproduce: 1.run_init /etc/init.d/network restart 2. 3. Actual results: Shutting down interface eth0: [ OK ] Shutting down loopback interface: [ OK ] error: "Operation not permitted" reading key "kernel.cap-bound" error: "Operation not permitted" reading key "kernel.cap-bound" Bringing up loopback interface: [ OK ] Bringing up interface eth0: [ OK ] Expected results: Shouldn't get those errors Additional info: I suspect this isn't a real problem but that the script should be hiding the message, or using sysctl to look for specific values rather than trying to get them all. I've assigned this to selinux-policy only because it doesn't happen in permissive mode, but the real problem is probably in the script.
In order to run sysctl -a you need to have sys_module privs, which is a very dangerous priv. So this is dontaudited in current policy but causes this error. This is actually a kernel bug. If as sysadm_t you just do a cat /proc/sys/kernel/cap-bound you get a Operation not permitted This triggers a capability sys_module. We currently dontaudit this in policy, but I think this is a problem, because this covers up the fact that some initscript might be trying to load kernel modules and we are not seeing the AVC's. I am reassiging this to the kernel since reading /proc/sys/kernel/cap-bound should not require sys_module privs.
I'm going to bring this up upstream and possibly get them to agree to allow reading of cap-bound without CAP_SYS_MODULE a policy question is why is this only showing up now and why is it (or is it) only a problem in the MLS policy? Nothing in kernel has changed in this area in a long long long time so why did the messages: error: "Operation not permitted" reading key "kernel.cap-bound" error: "Operation not permitted" reading key "kernel.cap-bound" start now? Is this both an MLS and a capability problem? Can someone with an MLS policy just allow the CAPABILITY:CAP_SYS_MODULE and help me understand that is the only problem?
I suspect its a strict policy issue. This is in the policy. looks like they turned off the avc record because they expected it. Maybe its just the console message that's new? allow initrc_t self:process { getpgid setsched setpgid setrlimit getsched setfscreate }; allow initrc_t self:capability ~{ sys_admin sys_module }; dontaudit initrc_t self:capability sys_module; # sysctl is triggering this allow initrc_t self:passwd rootok; Do you want me to change the above and give it a try? I've never built my own policy but will give it a try.
ok, i guess that makes sense. i think initrc_t is an unconfined domain in targeted (I think that means it would have cap_sys_module), which is why it only shows up in MLS policy, where I assume initrc_t is not an unconfined domain. I'll poke upstream kernel people about this now.
I tried changing the policy but got this: Compiling strict base module /usr/bin/checkmodule -M base.conf -o tmp/base.mod /usr/bin/checkmodule: loading policy configuration from base.conf libsepol.check_assertion_helper: assertion on line 81299 violated by allow initrc_t initrc_t:capability { sys_module }; libsepol.check_assertions: 1 assertion violations occured /usr/bin/checkmodule: expand module failed make: *** [tmp/base.mod] Error 1 error: Bad exit status from /var/tmp/rpm-tmp.9501 (%install) line 81299 is: neverallow ~{ can_load_kernmodule kern_unconfined } self:capability sys_module;
upstream kernel has accepted a change to this. I still don't know if it will make RHEL5 GA.
QE ack for RHEL5. Related to the LSPP release criteria.
Built into 2.6.18-1.3002.el5.
in 2.6.18-1.3002.el5
A package has been built which should help the problem described in this bug report. This report is therefore being closed with a resolution of CURRENTRELEASE. You may reopen this bug report if the solution does not work for you.