On 07/16/2014 03:00 PM, Stephen Smalley wrote:
> On 07/16/2014 11:53 AM, Dominick Grift wrote:
>> On Wed, 2014-07-16 at 11:11 -0400, Steve Lawrence wrote:
>> <snip>
>>> Hmm. I still can't get this error. The only thing I get with ausearch is
>>>
>>> type=USER_AVC msg=audit(1405522202.264:463): pid=1 uid=0 auid=4294967295
>>> ses=4294967295 subj=system_u:system_r:init_t:s0 msg='Unknown permission
>>> start for class system exe="/usr/lib/systemd/systemd" sauid=0 hostname=?
>>> addr=? terminal=?'
>>>
>>> Which looks correct. Fedora's latest policy does not include start in
>>> the system class:
>>>
>>> $ seinfo -csystem -x
>>> system
>>> status
>>> module_request
>>> reboot
>>> disable
>>> enable
>>> undefined
>>> ipc_info
>>> syslog_read
>>> halt
>>> reload
>>> syslog_console
>>> syslog_mod
>>>
>>> Also, the policy built with CIL on my machine allows the USER_AVC you're
>>> seeing:
>>>
>>> $ sesearch -A -s systemd_logind_t -t init_t -c service
>>> Found 2 semantic av rules:
>>> allow systemd_domain init_t : service { stop status reload start } ;
>>> allow systemd_logind_t init_t : service status ;
>>>
>>>
>>>
>>> Not sure if this would help, but it looks like you can set the boot
>>> parameter systemd.log_level=debug, and it should print all the selinux
>>> access checks, including which ones cause the "SELinux policy denies
>>> access" message. Unfortunately, I think the extra debug messages
>>> prevents my VM from booting, but you might have better luck.
>>>
>>
>> The same symptoms as with the classorder issue except that this time it
>> only happens once after the upgrade. Rebooting fixes the issue (?)
>>
>> That was not the case with the classorder issue.
>
> $ yum reinstall checkpolicy* libsepol* libsemanage* libselinux*
> policycoreutils* selinux-policy-targeted
> $ cp -a /sys/fs/selinux/class class.orig
> $ make -C selinux LIBDIR=/usr/lib64 SHLIBDIR=/lib64 install
> install-pywrap relabel
> $ ./selinux/libsemanage/utils/semanage_migrate_etc_to_var.py
> $ cp -a /sys/fs/selinux/class class.new
> $ diff -ru class.orig class.new
>
> Lots of differences in permission values.
>
Nice find! This looks like it's the problem. When we convert the base pp
to CIL, the permissions are output to CIL in the order that hashtab_map
receives them, which is is not in any particular order. So the
permission orders are all wrong, causing the values in the binary to be
different. I guess the kernel doesn't like when permission values change
when loading a new policy. And this explains why things work following a
reboot.
We've updated the pp2cil compiler to sort the permissions and output
them in the correct order. This change has been rebased and pushed to
the integration branch on github.
Thanks,
- Steve
_______________________________________________
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.
