On 07/18/2014 10:28 AM, Andy Ruch wrote:
> Thank you for the information. I see MAC_STATUS audits after a user calls setenforce but not during the boot process.
That would be consistent with a denial in enforcing mode; in that case,
the operation bails with EACCES and you will not generate the MAC_STATUS
audit message since no status change occurred.
> Here's a few more details. I install my custom policy during the post phase of the kickstart. After this, every time I boot I get the following audits:
>
>
> type=KERNEL msg=audit(1405633146.496:1): initialized
> type=MAC_POLICY_LOAD msg=audit(1405633148.645:2): policy loaded auid=4294967295 ses=4294967295
> type=SYSCALL msg=audit(1405633148.645:2): arch=c000003e syscall=1 success=yes exit=532798 a0=4 a1=7fa844c72000 a2=8213e a3=7fff6fce66d0 items=0 ppid=1 pid=771 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="load_policy" exe="/sbin/load_policy" subj=system_u:system_r:kernel_t:s0 key=(null)
>
>
> I will then update my policy using "rpm -Uvh". When I boot after that, I get:
>
> type=KERNEL msg=audit(1405633594.481:1): initialized
> type=MAC_POLICY_LOAD msg=audit(1405633596.598:2): policy loaded auid=4294967295 ses=4294967295
> type=SYSCALL msg=audit(1405633596.598:2): arch=c000003e syscall=1 success=yes exit=532798 a0=4 a1=7f58faf11000 a2=8213e a3=7fffaee3b2f0 items=0 ppid=1 pid=731 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="load_policy" exe="/sbin/load_policy" subj=system_u:system_r:kernel_t:s0 key=(null)
So policy was loaded by /sbin/load_policy, presumbly invoked by a script
from the initramfs with the -i option. This is specific to the way in
which RHEL 6 loads policy, which differs from RHEL 5 (or RHEL 7) as each
one had its own init system (SysVinit -> upstart -> systemd) and RHEL 6
chose to do it from the initramfs rather than from upstart IIRC.
> type=AVC msg=audit(1405633596.632:3): avc: denied { setenforce } for pid=772 comm="init" scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:security_t:s0 tclass=security
> type=SYSCALL msg=audit(1405633596.632:3): arch=c000003e syscall=1 success=no exit=-13 a0=1 a1=19d1b80 a2=2 a3=0 items=0 ppid=1 pid=772 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="init" exe="/bin/dash" subj=system_u:system_r:kernel_t:s0 key=(null)
That's an odd one; normally enforcing mode would already have been set
by load_policy -i so I do not know why dash is trying to set it here.
And I assume it must be trying to set it to permissive while it is
already enforcing, since a) we only check setenforce permission if the
new value differs from the old, and b) the system call would only fail
if we were already enforcing. I don't know if dash is trying to set
permissive to match your /etc/selinux/config (is it permissive or
enforcing?) or because it is trying to bail into some emergency shell or
what. I downloaded the CentOS 6.5 dash src rpm but I do not see that it
even calls setenforce anywhere. What's your dash and dracut version?
> This is when I boot into enforcing mode. When I change to boot into permissive, I don't see the AVC anymore. I would have expected to see the AVC but have it still allowed like normal permissive-mode behavior. Could this be related to having "selinux=1 enforcing=1" in the grub boot arguments? But why doesn't it happen when I initially install the system?
So if you boot with enforcing=1, then the kernel starts in enforcing
mode and load_policy -i should not try to change the enforcing mode at
all even if /etc/selinux/config says SELINUX=permissive. So any
subsequent attempt to switch to permissive by any of the initramfs
scripts will trigger a setenforce check and will fail if you have not
allowed kernel_t to do this.
If you boot without enforcing=1, then the kernel starts in permissive
mode, load_policy -i should set the enforcing mode to match
/etc/selinux/config. If /etc/selinux/config says permissive, then
you'll stay permissive and any subsequent setenforce 0 will be a no-op
and will not trigger a setenforce check at all. If /etc/selinux/config
says enforcing, then you should see the same behavior as with
enforcing=1 if an initramfs script tries to setenforce 0.
_______________________________________________
Selinux mailing list
Selinux@xxxxxxxxxxxxx
To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx.
To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
