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