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@xxxxxxxxxxxxxxxxxxxxxxx
> https://admin.fedoraproject.org/mailman/listinfo/selinux
--
selinux mailing list
selinux@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/selinux
