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

So if I understand correctly, there is the /var/tmp/initramfs* dir which is used as root directory created as initrc_tmp_t and this directory is used by ldconfig, depmod, right?

(In reply to comment #2)
> So if I understand correctly, there is the /var/tmp/initramfs* dir which is
> used as root directory created as initrc_tmp_t and this directory is used by
> ldconfig, depmod, right?

Yes, dracut create temp dir under /var/tmp, install files into it and run ldconfig -r, then create the cpio archive..

I have no knowledge about selinux, so not sure about initrc_tmp_t.

Ok, I am now playing with

# chcon -t kdump_exec_t /usr/bin/kdumpctl

It requires new transitions from kdump to other domains (we have a way how to do it) and I am able to get

allow ldconfig_t kdump_tmp_t:dir { read write add_name remove_name };
allow ldconfig_t kdump_tmp_t:file { rename write getattr setattr read create open };
allow ldconfig_t kdump_tmp_t:lnk_file read;

Well dracut wants to add lot of accesses but I think they are ok for kdump_t policy.

But also we could start to think about dracut policy  for these cases.

I would get rid of the transition to ldconfig, this domain only exists to make sure /etc/ld.so.cache file is labeled correctly.

Well this is about /var/tmp/initramfs* directory which is created by kdumpctl (labeled as bin_t) from the kdump.service unit file.

ExecStart=/usr/bin/kdumpctl start

All files/dirs are created there and ldconfig_t/insmod_t needs to manage /var/tmp/initramfs*. 

So my idea is the kdump_exec_t label for kdumpctl  => it will run as kdump_t and I could make kdump_t as initrc domain and could control which domains will able to use /var/tmp/initramfs* which could get kdump_tmp_t label.

Could you please test it with

http://koji.fedoraproject.org/koji/taskinfo?taskID=4179182

after install please execute

# chcon -t kdump_exec_t /usr/bin/kdumpctl

and try to re-test it. Thanks.

(In reply to comment #8)
> Could you please test it with
> 
> http://koji.fedoraproject.org/koji/taskinfo?taskID=4179182
> 
> after install please execute
> 
> # chcon -t kdump_exec_t /usr/bin/kdumpctl
> 
> and try to re-test it. Thanks.


Hi, there's new avc deny, see below info:

SELinux is preventing /usr/bin/bash from execute access on the file udevadm.

*****  Plugin catchall (100. confidence) suggests  ***************************

If you believe that bash should be allowed execute access on the udevadm file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep dracut /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:kdump_t:s0
Target Context                system_u:object_r:kdump_tmp_t:s0
Target Objects                udevadm [ file ]
Source                        dracut
Source Path                   /usr/bin/bash
Port                          <Unknown>
Host                          darkstar.nay.redhat.com
Source RPM Packages           bash-4.2.24-2.fc17.x86_64
Target RPM Packages           
Policy RPM                    selinux-policy-3.10.0-132.fc17.1.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     darkstar.nay.redhat.com
Platform                      Linux darkstar.nay.redhat.com 3.3.4-5.fc17.x86_64
                              #1 SMP Mon May 7 17:29:34 UTC 2012 x86_64 x86_64
Alert Count                   4
First Seen                    Wed 20 Jun 2012 04:02:38 PM CST
Last Seen                     Wed 20 Jun 2012 04:02:38 PM CST
Local ID                      52c97a48-d4c7-4584-af4f-429e3c5146ce

Raw Audit Messages
type=AVC msg=audit(1340179358.994:141): avc:  denied  { execute } for  pid=1844 comm="dracut" name="udevadm" dev="sda3" ino=404905 scontext=system_u:system_r:kdump_t:s0 tcontext=system_u:object_r:kdump_tmp_t:s0 tclass=file


type=SYSCALL msg=audit(1340179358.994:141): arch=x86_64 syscall=faccessat success=no exit=EACCES a0=ffffffffffffff9c a1=b0c430 a2=1 a3=2b items=0 ppid=1478 pid=1844 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=dracut exe=/usr/bin/bash subj=system_u:system_r:kdump_t:s0 key=(null)

Hash: dracut,kdump_t,kdump_tmp_t,file,execute

audit2allowunable to open /sys/fs/selinux/policy:  Permission denied


audit2allow -Runable to open /sys/fs/selinux/policy:  Permission denied

Could you test it in permissive mode?

# setenforce 0

(In reply to comment #10)
> Could you test it in permissive mode?
> 
> # setenforce 0

the service startup ok with permissive mode

and what avc msgs are you getting?

See below, not sure if it's what you want:

SELinux is preventing /usr/bin/rm from unlink access on the chr_file null.

*****  Plugin catchall (100. confidence) suggests  ***************************

If you believe that rm should be allowed unlink access on the null chr_file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep rm /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:kdump_t:s0
Target Context                system_u:object_r:null_device_t:s0
Target Objects                null [ chr_file ]
Source                        rm
Source Path                   /usr/bin/rm
Port                          <Unknown>
Host                          darkstar.nay.redhat.com
Source RPM Packages           coreutils-8.15-6.fc17.x86_64
Target RPM Packages           
Policy RPM                    selinux-policy-3.10.0-132.fc17.1.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Permissive
Host Name                     darkstar.nay.redhat.com
Platform                      Linux darkstar.nay.redhat.com 3.3.4-5.fc17.x86_64
                              #1 SMP Mon May 7 17:29:34 UTC 2012 x86_64 x86_64
Alert Count                   2
First Seen                    Wed 20 Jun 2012 04:50:15 PM CST
Last Seen                     Wed 20 Jun 2012 05:11:59 PM CST
Local ID                      c68ddcd7-31c9-4265-a81f-632d92ca597f

Raw Audit Messages
type=AVC msg=audit(1340183519.652:308): avc:  denied  { unlink } for  pid=17448 comm="rm" name="null" dev="sda3" ino=404598 scontext=system_u:system_r:kdump_t:s0 tcontext=system_u:object_r:null_device_t:s0 tclass=chr_file


type=SYSCALL msg=audit(1340183519.652:308): arch=x86_64 syscall=unlinkat success=yes exit=0 a0=5 a1=14989e8 a2=0 a3=114 items=0 ppid=13940 pid=17448 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=rm exe=/usr/bin/rm subj=system_u:system_r:kdump_t:s0 key=(null)

Hash: rm,kdump_t,null_device_t,chr_file,unlink

audit2allowunable to open /sys/fs/selinux/policy:  Permission denied


audit2allow -Runable to open /sys/fs/selinux/policy:  Permission denied

Ok, I think I have a solution.

Could you test it with

http://koji.fedoraproject.org/koji/taskinfo?taskID=4183110

(In reply to comment #14)
> Ok, I think I have a solution.
> 
> Could you test it with
> 
> http://koji.fedoraproject.org/koji/taskinfo?taskID=4183110

With this build systemd service startup ok for me. Great work, thanks!

Fixed in selinux-policy-3.10.0-132.fc17

selinux-policy-3.10.0-134.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/selinux-policy-3.10.0-134.fc17

Package selinux-policy-3.10.0-134.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing selinux-policy-3.10.0-134.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-10008/selinux-policy-3.10.0-134.fc17
then log in and leave karma (feedback).

selinux-policy-3.10.0-134.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.