Bug 1044299

I'm able to reproduce this bug in RHEL7 beta. The issue disappears with SELinux switched to permissive mode. I suspect that this is caused by bug#1022762 and bug#1035360, the same AVCs can be seen in audit.log.

Switching to selinux-policy component.

policy version: selinux-policy-3.12.1-118.el7.noarch

AVC (similar to bug#1022762):
type=USER_AVC msg=audit(1390303008.005:712): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc:  denied  { enable } for auid=-1 uid=0 gid=0 scontext=system_u:system_r:kdumpgui_t:s0-s0:c0.c1023 tcontext=system_u:system_r:init_t:s0 tclass=system  exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'

Yes, it needs to be fixed in the systemd.

This one is probably clone of https://bugzilla.redhat.com/show_bug.cgi?id=1056008

*** Bug 1058697 has been marked as a duplicate of this bug. ***

Even with the systemd fix (#1056008), the issue still persists.

With systemd-208-4.el7, I'm getting slightly different USER_AVC:

type=USER_AVC msg=audit(1392660188.972:385): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc:  denied  { enable } for auid=-1 uid=0 gid=0 path="system" scontext=system_u:system_r:kdumpgui_t:s0-s0:c0.c1023 tcontext=system_u:system_r:init_t:s0 tclass=system exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'

Doesn't the policy need to be changed too, as suggested in bug #1035360?

It does not make sense to do this check on the "system" class.

Caught in enforcing mode:
----
type=PATH msg=audit(02/20/2014 09:22:11.940:14628) : item=0 name=/dev/sr0 inode=9941 dev=00:05 mode=block,660 ouid=root ogid=cdrom rdev=0b:00 obj=system_u:object_r:removable_device_t:s0 objtype=NORMAL 
type=CWD msg=audit(02/20/2014 09:22:11.940:14628) :  cwd=/ 
type=SYSCALL msg=audit(02/20/2014 09:22:11.940:14628) : arch=x86_64 syscall=open success=no exit=-13(Permission denied) a0=0x7896e0 a1=O_RDONLY|O_CLOEXEC a2=0x0 a3=0x0 items=1 ppid=1713 pid=1715 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=grubby exe=/usr/sbin/grubby subj=system_u:system_r:kdumpgui_t:s0-s0:c0.c1023 key=(null) 
type=AVC msg=audit(02/20/2014 09:22:11.940:14628) : avc:  denied  { read } for  pid=1715 comm=grubby name=sr0 dev="devtmpfs" ino=9941 scontext=system_u:system_r:kdumpgui_t:s0-s0:c0.c1023 tcontext=system_u:object_r:removable_device_t:s0 tclass=blk_file 
----
type=USER_AVC msg=audit(02/20/2014 09:23:07.937:14632) : pid=1 uid=root auid=unset ses=unset subj=system_u:system_r:init_t:s0 msg='avc:  denied  { enable } for auid=unset uid=root gid=root path=system scontext=system_u:system_r:kdumpgui_t:s0-s0:c0.c1023 tcontext=system_u:system_r:init_t:s0 tclass=system  exe=/usr/lib/systemd/systemd sauid=root hostname=? addr=? terminal=?' 
----

Caught in permissive mode:
----
type=USER_AVC msg=audit(02/20/2014 10:06:07.061:14878) : pid=1 uid=root auid=unset ses=unset subj=system_u:system_r:init_t:s0 msg='avc:  denied  { enable } for auid=unset uid=root gid=root path=system scontext=system_u:system_r:kdumpgui_t:s0-s0:c0.c1023 tcontext=system_u:system_r:init_t:s0 tclass=system  exe=/usr/lib/systemd/systemd sauid=root hostname=? addr=? terminal=?' 
----
type=USER_AVC msg=audit(02/20/2014 10:06:07.062:14879) : pid=1 uid=root auid=unset ses=unset subj=system_u:system_r:init_t:s0 msg='avc:  denied  { reload } for auid=unset uid=root gid=root path=system scontext=system_u:system_r:kdumpgui_t:s0-s0:c0.c1023 tcontext=system_u:system_r:init_t:s0 tclass=system  exe=/usr/lib/systemd/systemd sauid=root hostname=? addr=? terminal=?' 
----

*** Bug 1070318 has been marked as a duplicate of this bug. ***

Created attachment 868096 [details]
sos report

default comment by bridge

Created attachment 868097 [details]
screenshot

default comment by bridge

Ia m not sure what is the proper fix in systemd. I think that maybe the mentioned patch from upstream http://cgit.freedesktop.org/systemd/systemd/commit/?id=4f7385f is wrong, because when the service is not running u = manager_get_unit(m, *i); will just return an error, so we will not get to the selinux_unit_access_check part.

The problem is it would allow s-c-kdump to enable/disable all services on the system. 

Either we miss a check on

/usr/lib/systemd/system/httpd.service

or we miss additional check on this unit file.

Can you please elaborate this? I am not sure that I follow.

My point is 

allow kdumpgui_t init_t:system { enable disalbe reload }

could be OK but then we need to have additional check on kdump unit file in this case?

Dan?

*** Bug 1056008 has been marked as a duplicate of this bug. ***

Lukáš.
my understanding is we don't do a check for a unit file if there is disable/enable action. Not sure if it can be changed to do this check or we need to add an additional check after

allow kdumpgui_t init_t:system { enable disalbe reload }

is ok and then do a unit file check.

Does it make sense?

I am still not sure what is exactly happening here. It looks to me that kdumpgui is calling enable on some unit, but selinux forbids that.

So from systemd side of a view we should check if some binary is allowed to enable specific unit? Or is this just a question about policy if kdumpgui can enable and disable units?

(In reply to Lukáš Nykrýn from comment #24)
> I am still not sure what is exactly happening here. It looks to me that
> kdumpgui is calling enable on some unit, but selinux forbids that.

Yes.

s-c-kdump running as kdumpgui_t runs

systemctl enable/disable kdump

so you end with

allow kdumpgui_t init_t:system { enable disable reload }

But it allows s-c-kdump to disable/enable all services on a system.

> So from systemd side of a view we should check if some binary is allowed to
> enable specific unit? Or is this just a question about policy if kdumpgui
> can enable and disable units?

The same way how you check whether it can be started for example.

*** Bug 1055488 has been marked as a duplicate of this bug. ***

------- Comment From brueckner.com 2014-03-11 15:26 EDT-------
*** Bug 105558 has been marked as a duplicate of this bug. ***

This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.