staff_u unable to run ls in /var on one system

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/13/2013 02:38 PM, Erinn Looney-Triggs wrote:
> On 03/13/2013 10:17 AM, Dominick Grift wrote:
>> On Wed, 2013-03-13 at 09:36 -0600, Erinn Looney-Triggs wrote:
>>> I have an odd problem. Users running as staff_u are unable to run ls
>>> in /var on one system only (though I haven't tested all of them).
>>> 
>>> It is definetly an SELinux thing, setenforce 0, problem goes away, 
>>> setenforce 1, problem returns. ausearch -m avc -ts now shows nothing.
>>> 
>>> restorecon on /var yields nothing and the labels are the same from one 
>>> system to the next.
>>> 
>>> id -Z staff_u:staff_r:staff_t:s0-s0:c0.c1023
>>> 
>>> Same on both systems (this is set via IPA and SSSD)
>>> 
>>> So I can't really figure out where the problem lies:
>>> 
>>> ls -lZd /var drwxr-xr-x. root root system_u:object_r:var_t:s0
>>> /var
>>> 
>>> Any ideas?
>>> 
>>> -Erinn
>>> 
>> 
>> If SELinux blocks it logs the denial. Sometimes the event is silently 
>> denied (like probably in your case). In that case you can temporarily 
>> expose hidden denials by running: semodule -DB. Use this to get the AVC 
>> denial of the event (reproduce the event). After you have the AVC denial,
>> run: semodule -B to load the policy with the hidden denial runs 
>> re-inserted.
>> 
>> Now that you have the AVC denial of the event you can use this 
>> information to query the policy.
>> 
>> I will just make some assumptions here:
>> 
>> 1. source context type is: staff_t 2. target context type is: var_t 3.
>> target security class is: dir 4. permission is: read
>> 
>> When one runs ls in /var, one actually reads the /var directory file to 
>> get the entries (e.g. listing the contents of the directory)
>> 
>> Now one can use the sesearch command to see if the policy allows this. If
>> it does it will return a rule matching your query:
>> 
>> sesearch -ASCT -s staff_t -t var_t -c dir -p read
>> 
>> Example (Fedora 18)
>> 
>>> # sesearch -ASCT -s staff_t -t var_t -c dir -p read Found 1 semantic av
>>> rules: allow staff_usertype var_t : dir { ioctl read getattr lock
>>> search open } ;
>> 
>> So in Fedora 18 staff_t is allowed to read directory files with type 
>> var_t.
>> 
>> If you follow these steps then you should be able to figure out why it is
>> allowed on one system but not on another system.
>> 
>> One reason could be that each system has a different policy.
>> 
>> In the past staff was not allowed to list /var but i suppose that has 
>> recently changed.
>> 
>>> -- selinux mailing list selinux at lists.fedoraproject.org 
>>> https://admin.fedoraproject.org/mailman/listinfo/selinux
>> 
>> 
> 
> Dominick, Thank you kindly for the detailed info I really appreciate it.
> 
> It was a policy difference and now that I know how to track it down it 
> makes it much easier to do in the future.
> 
> However, even after running semodule -DB my ausearch never turned up any 
> results. Perhaps I am doing it incorrectly, I ran ausearch -m AVC -ts today
> and can't find anything.
> 
> Anyway, thanks again for the help.
> 
> -Erinn
> 
> 
> 
> 
> 
> 
> -- selinux mailing list selinux at lists.fedoraproject.org 
> https://admin.fedoraproject.org/mailman/listinfo/selinux
> 
I would bet your auditd is not running.

Restart it.  You might be seeing AVC's in /var/log/messages


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlFAyeEACgkQrlYvE4MpobN0HwCgwmBovW37A6lm4HMbApEzJaEu
v+gAnjJXfjLt+LIv6pCAJ8AQug+Z5/px
=wlBB
-----END PGP SIGNATURE-----