Bug 675000 - cgrulesengd cannot be started from initscript with selinux target policy enabled
Summary: cgrulesengd cannot be started from initscript with selinux target policy enabled
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: selinux-policy
Version: 6.1
Hardware: All
OS: Linux
high
high
Target Milestone: rc
: 6.1
Assignee: Miroslav Grepl
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-02-03 21:33 UTC by Mike Gahagan
Modified: 2012-10-15 15:03 UTC (History)
5 users (show)

Fixed In Version: selinux-policy-3.7.19-69.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-05-19 11:57:30 UTC
Target Upstream Version:


Attachments (Terms of Use)
audit denials for cgred_t (6.81 KB, text/plain)
2011-02-09 21:15 UTC, Mike Gahagan
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:0526 0 normal SHIPPED_LIVE selinux-policy bug fix and enhancement update 2011-05-19 09:37:41 UTC

Description Mike Gahagan 2011-02-03 21:33:16 UTC
Description of problem:

Cannot start with selinux enforcing enabled:
[root@test1169 ~]# service cgred start
Starting CGroup Rules Engine Daemon:                       [  OK  ]
[root@test1169 ~]# ps ax | grep cg
 1321 pts/0    S+     0:00 grep cg
[root@test1169 ~]# service cgred status
cgred dead but pid file exists
[root@test1169 ~]# service cgred stop
Stopping CGroup Rules Engine Daemon...                     [FAILED]
[root@test1169 ~]# service cgred stop
Stopping CGroup Rules Engine Daemon...                     [  OK  ]

disable enforcing....
[root@test1169 ~]# setenforce 0
[root@test1169 ~]# service cgred start
Starting CGroup Rules Engine Daemon:                       [  OK  ]
[root@test1169 ~]# service cgred status
cgred (pid  1361) is running...
[root@test1169 ~]# ps ax | grep cg
 1361 ?        Ss     0:00 /sbin/cgrulesengd -g cgred
 1373 pts/0    S+     0:00 grep cg
[root@test1169 ~]# service cgred stop
Stopping CGroup Rules Engine Daemon...                     [  OK  ]
[root@test1169 ~]# service cgred status
cgred is stopped
[root@test1169 ~]# ps ax | grep cg
 1393 pts/0    S+     0:00 grep cg

I can however start the service by hand with selinux enabled:
[root@test1169 ~]# setenforce 1
[root@test1169 ~]# getenforce
Enforcing
[root@test1169 ~]# /sbin/cgrulesengd -g cgred
[root@test1169 ~]# ps ax | grep cg
 1402 ?        Ss     0:00 /sbin/cgrulesengd -g cgred
 1405 pts/0    S+     0:00 grep cg


Version-Release number of selected component (if applicable):
[root@test1169 ~]# uname -r
2.6.32-112.el6.i686.debug
[root@test1169 ~]# rpm -qa | grep selinux
selinux-policy-3.7.19-67.el6.noarch
libselinux-2.0.94-2.el6.i686
libselinux-utils-2.0.94-2.el6.i686
selinux-policy-targeted-3.7.19-67.el6.noarch
[root@test1169 ~]# rpm -q libcgroup
libcgroup-0.37-1.el6.i686


How reproducible:
always
It makes no difference if I use the service command or /etc/init.d/ 
I have also reproduced this on x86_64 with and without the debug kernel.

Steps to Reproduce:
1.Start the cgconfig service, then attempt to start cgred via the initscripts
2.
3.
  
Actual results:
init script reports service started, however it did  not

type=AVC msg=audit(1296768725.309:23): avc:  denied  { unlink } for  pid=1426 comm="cgrulesengd" name="cgred.socket" dev=dm-0 ino=140687 scontext=unconfined_u:system_r:cgred_t:s0 tcontext=unconfined_u:object_r:var_run_t:s0 tclass=sock_file
type=SYSCALL msg=audit(1296768725.309:23): arch=40000003 syscall=10 success=no exit=-13 a0=804aac9 a1=0 a2=2 a3=bfcb45de items=0 ppid=1 pid=1426 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="cgrulesengd" exe="/sbin/cgrulesengd" subj=unconfined_u:system_r:cgred_t:s0 key=(null)

Expected results:
Service starts

Additional info:

Comment 2 Jan Safranek 2011-02-04 13:57:35 UTC
cgrulesengd has changed a lot in RHEL 6.1, the SELinux policy needs to be updated accordingly.

Comment 3 Daniel Walsh 2011-02-04 14:08:15 UTC
This looks like a labeling issue.  Where is the cgred.socket created?

Comment 4 Jan Safranek 2011-02-04 14:30:41 UTC
(In reply to comment #3)
> This looks like a labeling issue.  Where is the cgred.socket created?

/var/run/cgred.socket

Comment 5 Daniel Walsh 2011-02-04 14:52:05 UTC
I guess you are back porting all the stuff that is in F15?  Miroslav, lets backport all of cgroup.* to RHEL6

Comment 6 Miroslav Grepl 2011-02-07 15:41:50 UTC
Fixed in selinux-policy-3.7.19-69.el6

Comment 8 Mike Gahagan 2011-02-08 21:42:40 UTC
It looks like we get by the unlink denial, but now I'm seeing a different avc this time which is causing the service to fail to start similar to the symptom before. I can confirm everything starts as expected when I disable selinux enforcing.

type=AVC msg=audit(1297201222.766:16647): avc:  denied  { chown } for  pid=19763 comm="cgrulesengd" capability=0  scontext=unconfined_u:system_r:cgred_t:s0 tcontext=unconfined_u:system_r:cgred_t:s0 tclass=capability
type=SYSCALL msg=audit(1297201222.766:16647): arch=c000003e syscall=92 success=no exit=-1 a0=40312d a1=ffffffff a2=1f4 a3=0 items=0 ppid=1 pid=19763 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="cgrulesengd" exe="/sbin/cgrulesengd" subj=unconfined_u:system_r:cgred_t:s0 key=(null)

[root@test1239 libcgroup-tools-tests]# rpm -qa | grep selinux
selinux-policy-targeted-3.7.19-69.el6.noarch
selinux-policy-3.7.19-69.el6.noarch
libselinux-2.0.94-2.el6.x86_64
libselinux-utils-2.0.94-2.el6.x86_64
[root@test1239 libcgroup-tools-tests]# rpm -q libcgroup
libcgroup-0.37-1.el6.x86_64
[root@test1239 libcgroup-tools-tests]# uname -r
2.6.32-115.el6.x86_64

I did a 'touch /.autorelabel' and rebooted the machine before testing.

Comment 10 Miroslav Grepl 2011-02-09 08:41:39 UTC
I am fixing it. Thanks.

Mike,
could you add a local policy and make sure it works in Enforcing.

# grep cgred_t /var/log/audit/audit.log | audit2allow -M mycgroup
# semodule -i mycgroup.pp

Comment 11 Mike Gahagan 2011-02-09 21:15:56 UTC
Created attachment 477910 [details]
audit denials for cgred_t

Comment 12 Mike Gahagan 2011-02-09 21:17:31 UTC
Here is the ruleset from audit2allow, the audit logs from cgred_t are in the attachment in comment 11.

[mpg@dhcp231-174 x86_64]$ cat /tmp/mycgroup.te 

module mycgroup 1.0;

require {
	type cgred_t;
	class capability { chown fsetid };
}

#============= cgred_t ==============
allow cgred_t self:capability { chown fsetid };

Comment 13 Mike Gahagan 2011-02-09 21:20:07 UTC
I have confirmed the ruleset in comment# 12 has fixed this issue for me. Every item for the libcgroup init script sanity test we have now passes except for one which is failing due to the init script exiting with the wrong code which I'll take up in a separate bz as it has nothing to do with selinux policy.

Comment 14 Milos Malik 2011-02-16 08:58:07 UTC
Easy to reproduce without the local policy mentioned in comment#12:

----
time->Wed Feb 16 03:55:02 2011
type=SYSCALL msg=audit(1297846502.811:21): arch=c000003e syscall=92 success=no exit=-1 a0=40312d a1=ffffffff a2=1f4 a3=7fff8fb8f910 items=0 ppid=1 pid=10919 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="cgrulesengd" exe="/sbin/cgrulesengd" subj=unconfined_u:system_r:cgred_t:s0 key=(null)
type=AVC msg=audit(1297846502.811:21): avc:  denied  { chown } for  pid=10919 comm="cgrulesengd" capability=0  scontext=unconfined_u:system_r:cgred_t:s0 tcontext=unconfined_u:system_r:cgred_t:s0 tclass=capability
----

Comment 15 Miroslav Grepl 2011-02-17 15:24:43 UTC
Fixed in selinux-policy-3.7.19-71.el6

Comment 18 errata-xmlrpc 2011-05-19 11:57:30 UTC
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 therefore 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-2011-0526.html


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