From: "Dominick Grift" dominick.grift@gmail.com On Thu, 2013-11-14 at 17:45 -0500, m.roth@5-cent.us wrote:
Dominick Grift wrote:
On Thu, 2013-11-14 at 17:01 -0500, m.roth@5-cent.us wrote:
I really don't understand this: CentOS 6.4 directory: user_t subdirectory: httpd_sys_content_t file: httpd_sys_content_t
(Permissive mode) selinux preventing search access on the subdirectory by httpd.
Is this a cascading issue, that selinux doesn't like apache trying to access something under usr_t?
<snip>
But you want optimal help then you should enclose the actual avc denial
because now its all hearsay. i need to look at the facts to be able to suggest something i can vouch for
Good thought. NOW I'm *really* confused. ll -Z of the file gives me -rw-r--r--. <user> <group> system_u:system_r:httpd_sys_content_t:s0 <file>
Meanwhile, grep avc /var/log/audit/audit.log | grep <filename> gets me: <...> type=AVC msg=audit(1384527075.382:7606586): avc: denied { read } for pid=1329 comm="httpd" name="<filename>" dev=sdc1 ino=66691074 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=file
"Unlabeled_t"?
mark
On Fri, 2013-11-15 at 10:46 -0500, m.roth@5-cent.us wrote:
Good thought. NOW I'm *really* confused. ll -Z of the file gives me -rw-r--r--. <user> <group> system_u:system_r:httpd_sys_content_t:s0 <file>
Meanwhile, grep avc /var/log/audit/audit.log | grep <filename> gets me: <...> type=AVC msg=audit(1384527075.382:7606586): avc: denied { read } for pid=1329 comm="httpd" name="<filename>" dev=sdc1 ino=66691074 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=file
"Unlabeled_t"?
You should probably watch some of my videos on youtube (1)
Because in some of those videos i explain what it means if you see entities with the unlabeled_t type security identifier
But i will give you a run-down of it here:
There is this concept of "initial security identifiers" in SELinux. Initial security identifiers are security identifiers that are hard-coded into SELinux
Initial security identifiers are used to address three security challenges:
1. deal with system initialization 2. deal with fixed resources 3. deal with fail-over
I will touch on the third challenge, because this is related to your issue
Basically, SELinux uses initial sids for fail-over because:
SELinux needs a way to deal with mislabeled, and unlabeled files on running systems.
The unlabeled initial sid is associated to entities by SELinux if a entity has one or more invalid security indentifiers
The unlabeled_t security identifier is associated to the unlabeled initial security identifier
So lets put that into context of your issue
You have the following denial:
avc: denied { read } for pid=1329 comm="httpd" name="<filename>" dev=sdc1 ino=66691074 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=file
You have the "<filename>" file labeled as follows:
system_u:system_r:httpd_sys_content_t:s0
We know that SELinux associates the unlabeled_t security identifier to entities if the entity has one or more invalid security identifier
So we know the file has one or more invalid security identifier
The invalid security identifier in this case is the system_r role security identifier.
On file system objects like files only the object_r role security identifier is valid (if you want to know why watch my "selinux explained" video on you tube (1)
So to get rid of the unlabeled_t issue you need to change the role security identifier of the file called "<filename>"
for example: chcon -r object_r "<filename>"
..And remember, on file system objects the role sid should always be object_r
Dominick Grift wrote:
On Fri, 2013-11-15 at 10:46 -0500, m.roth@5-cent.us wrote:
Good thought. NOW I'm *really* confused. ll -Z of the file gives me -rw-r--r--. <user> <group> system_u:system_r:httpd_sys_content_t:s0
<file>
Meanwhile, grep avc /var/log/audit/audit.log | grep <filename> gets me: <...> type=AVC msg=audit(1384527075.382:7606586): avc: denied { read } for pid=1329 comm="httpd" name="<filename>" dev=sdc1 ino=66691074 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=file
"Unlabeled_t"?
You should probably watch some of my videos on youtube (1)
I'm not really big, most of the time, on instructional videos - I'd rather read. This email was just what I needed.
Because in some of those videos i explain what it means if you see entities with the unlabeled_t type security identifier
But i will give you a run-down of it here:
There is this concept of "initial security identifiers" in SELinux. Initial security identifiers are security identifiers that are hard-coded into SELinux
Initial security identifiers are used to address three security challenges:
- deal with system initialization
- deal with fixed resources
- deal with fail-over
I will touch on the third challenge, because this is related to your issue
Basically, SELinux uses initial sids for fail-over because:
SELinux needs a way to deal with mislabeled, and unlabeled files on running systems.
The unlabeled initial sid is associated to entities by SELinux if a entity has one or more invalid security indentifiers
And here's my complaint: why should it tell me that it's unlabeled_t, rather than telling me "system_r is an invalid role"?
One more detail - I made a typo, and managed chcon -R -r system_u, rather than -u... and chcon accepted it. Isn't there any parm checking, to match what you're changing to the context?
Thanks, again, for the clear explanation.
mark
On Fri, 2013-11-15 at 11:28 -0500, m.roth@5-cent.us wrote:
And here's my complaint: why should it tell me that it's unlabeled_t, rather than telling me "system_r is an invalid role"?
Good point, would be nicer if it would not allow one to change to invalid identifiers in the first place.
I cannot answer the question why one is allowed to chcon -r system_r <file> in the first place. (might be some technical limitation)
However the unlabeled isid and unlabeled_t sid are there for fail-over so that security is not compromised if it does happen
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/15/2013 11:44 AM, Dominick Grift wrote:
On Fri, 2013-11-15 at 11:28 -0500, m.roth@5-cent.us wrote:
And here's my complaint: why should it tell me that it's unlabeled_t, rather than telling me "system_r is an invalid role"?
Good point, would be nicer if it would not allow one to change to invalid identifiers in the first place.
I cannot answer the question why one is allowed to chcon -r system_r <file> in the first place. (might be some technical limitation)
However the unlabeled isid and unlabeled_t sid are there for fail-over so that security is not compromised if it does happen
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
Looks like a bug to me.
Should have generated an MAC_ADMIN avc.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/15/2013 11:28 AM, m.roth@5-cent.us wrote:
Dominick Grift wrote:
On Fri, 2013-11-15 at 10:46 -0500, m.roth@5-cent.us wrote:
Good thought. NOW I'm *really* confused. ll -Z of the file gives me -rw-r--r--. <user> <group> system_u:system_r:httpd_sys_content_t:s0
<file>
Meanwhile, grep avc /var/log/audit/audit.log | grep <filename> gets me: <...> type=AVC msg=audit(1384527075.382:7606586): avc: denied { read } for pid=1329 comm="httpd" name="<filename>" dev=sdc1 ino=66691074 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=file
"Unlabeled_t"?
You should probably watch some of my videos on youtube (1)
I'm not really big, most of the time, on instructional videos - I'd rather read. This email was just what I needed.
Because in some of those videos i explain what it means if you see entities with the unlabeled_t type security identifier
But i will give you a run-down of it here:
There is this concept of "initial security identifiers" in SELinux. Initial security identifiers are security identifiers that are hard-coded into SELinux
Initial security identifiers are used to address three security challenges:
- deal with system initialization 2. deal with fixed resources 3. deal
with fail-over
I will touch on the third challenge, because this is related to your issue
Basically, SELinux uses initial sids for fail-over because:
SELinux needs a way to deal with mislabeled, and unlabeled files on running systems.
The unlabeled initial sid is associated to entities by SELinux if a entity has one or more invalid security indentifiers
And here's my complaint: why should it tell me that it's unlabeled_t, rather than telling me "system_r is an invalid role"?
One more detail - I made a typo, and managed chcon -R -r system_u, rather than -u... and chcon accepted it. Isn't there any parm checking, to match what you're changing to the context?
Thanks, again, for the clear explanation.
mark
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
I have a request into the kernel guys to give us the real label in the AVC, so we could have setroubleshoot attempt to tell you what is wrong, Currently the kernel gives you unlebaled_t no matter what.
Daniel J Walsh wrote:
On 11/15/2013 11:28 AM, m.roth@5-cent.us wrote:
Dominick Grift wrote:
On Fri, 2013-11-15 at 10:46 -0500, m.roth@5-cent.us wrote:
Good thought. NOW I'm *really* confused. ll -Z of the file gives me -rw-r--r--. <user> <group> system_u:system_r:httpd_sys_content_t:s0
<file>
Meanwhile, grep avc /var/log/audit/audit.log | grep <filename> gets me: <...> type=AVC msg=audit(1384527075.382:7606586): avc: denied { read } for pid=1329 comm="httpd" name="<filename>" dev=sdc1 ino=66691074 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=file
"Unlabeled_t"?
<snip>
And here's my complaint: why should it tell me that it's unlabeled_t, rather than telling me "system_r is an invalid role"?
One more detail - I made a typo, and managed chcon -R -r system_u, rather than -u... and chcon accepted it. Isn't there any parm checking, to match what you're changing to the context?
<snip>
I have a request into the kernel guys to give us the real label in the AVC, so we could have setroubleshoot attempt to tell you what is wrong,
Currently
the kernel gives you unlebaled_t no matter what.
Thank you - I don't want to bitch and moan, I'd rather get things fixed, so I can go on to new and more interesting problems.
mark
selinux@lists.fedoraproject.org