staff_u unable to run ls in /var on one system

[Daniel J Walsh]

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

On 03/13/2013 12:17 PM, 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
> 
> 
> -- selinux mailing list selinux at lists.fedoraproject.org 
> https://admin.fedoraproject.org/mailman/listinfo/selinux
> 
We have dontaudit rules for getattr and perhaps listing of directories to stop
staff_t or other unconfined domains from generating thousands of AVC messages.

For example ls /usr/bin from a confined user could generate lots of SELinux
blocks.  Similarly ps -eZ, or even bash command completion.  One would figure
you are hitting these dontaudit rules.


On Fedora 19 I see these rules

 sesearch -A -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 staff domains are allowed to list the contents of /var, but if a directory
under /var has a different label, staff_t could be blocked.

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

iEYEARECAAYFAlFAu3AACgkQrlYvE4MpobPRAwCgx4kkJLLERSQSy+BMSo+vhNRm
7NsAn13dJVw5iDV7p4J6SxAd1iFIFup5
=suXK
-----END PGP SIGNATURE-----