Re: staff_u unable to run ls in /var on one system

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(a)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(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux

-----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-----