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
On 03/13/2013 09:36 AM, 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
Replying to myself here as I realize I didn't give enough information.
This is on RHEL 6.4 systems with selinux-policy-3.7.19-195.el6_4.3.noarch
-Erinn
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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
-----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:
- 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
-- selinux mailing list selinux@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.
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:
- source context type is: staff_t
- target context type is: var_t
- target security class is: dir
- 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@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
-----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:
- 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@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@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
selinux@lists.fedoraproject.org