Bug 219230 - LSPP: error message when starting the network
LSPP: error message when starting the network
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Eric Paris
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2006-12-11 18:52 EST by Linda Knippers
Modified: 2007-11-30 17:07 EST (History)
6 users (show)

See Also:
Fixed In Version: RC
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-02-07 20:40:07 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Linda Knippers 2006-12-11 18:52:50 EST
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

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:

Steps to Reproduce:
1.run_init /etc/init.d/network restart
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.
Comment 1 Daniel Walsh 2006-12-12 10:06:19 EST
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.

Comment 3 Eric Paris 2006-12-15 13:26:39 EST
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
Comment 4 Linda Knippers 2006-12-15 14:10:01 EST
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.
Comment 5 Eric Paris 2006-12-15 14:35:29 EST
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.
Comment 6 Linda Knippers 2006-12-15 14:43:57 EST
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;

Comment 7 Eric Paris 2006-12-22 14:50:04 EST
upstream kernel has accepted a change to this.  I still don't know if it will
make RHEL5 GA.
Comment 8 Jay Turner 2007-01-02 10:08:02 EST
QE ack for RHEL5.  Related to the LSPP release criteria.
Comment 11 Jay Turner 2007-01-10 10:31:41 EST
Built into 2.6.18-1.3002.el5.
Comment 13 Don Zickus 2007-01-10 18:56:30 EST
in 2.6.18-1.3002.el5
Comment 14 RHEL Product and Program Management 2007-02-07 20:40:07 EST
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.

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