On 07/17/2014 09:49 AM, Steve Lawrence wrote:
> 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.
I think the kernel is fine with it, but not all userspace object
managers will be. Legacy userspace object managers may still be using
fixed permission values from selinux/av_permissions.h, and even modern
ones may be only mapping classes/permissions once at startup (via
selinux_set_mapping) and then assuming that this mapping is stable at
runtime. Even for userspace object managers that are using
selinux_check_access(), libselinux/src/stringrep.c currently caches the
class/perm values on first lookup and does not flush this cache from
avc_reset upon policy reload notification - that's likely a bug that
should be fixed. But even if we fix it there, there is no current
atomicity provided within selinux_check_access() around the class/perm
lookup and the AVC lookup so they could end up being inconsistent. In
short, we don't currently guarantee that changing class/perm values at
runtime without a reboot will work.
> 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.
_______________________________________________
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.
