On Fri, 2013-05-03 at 10:15 -0500, Jason L Tibbitts III wrote:
>>>>> "NM" == Nicolas Mailhot
<nicolas.mailhot(a)laposte.net> writes:
NM> I don't think selinux will block web server accesses to
NM> /usr/share/fonts/something, since we deploy webapps in
NM> /usr/share/something_else, which is pretty much the same namespace.
Well, there are a whole lot of specific fcontext entries for content in
/usr/share, including fonts which get their own type (fonts_t). I
certainly wouldn't assume that it would simply work, though it would be
fairly easy for the policy to adapt if it didn't. My point was simply
that there are other configurations besides "fix it with mod_alias".
Yeah. Obviously the sensible thing is to check, but since httpd is such
a sensitive component, it has a very restrictive selinux policy. I tend
to treat it as a rule of thumb that httpd can't read anything unless
it's httpd_sys_content_t or httpd_sys_rw_content_t . It's *certainly*
not safe to assume that httpd can or should be able to 'at least read'
any old thing in /usr , or /usr/share , or any other system path;
vulnerabilities that let some webapp read /etc/passwd or some other
sensitive file are a dime a dozen, and that's certainly one of the
things SELinux aims to mitigate.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net