staff_u unable to run ls in /var on one system

[Erinn Looney-Triggs]

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




-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 555 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/selinux/attachments/20130313/58008c98/attachment.sig>