awilliam at redhat.com
Sat May 4 02:05:59 UTC 2013
On Fri, 2013-05-03 at 10:15 -0500, Jason L Tibbitts III wrote:
> >>>>> "NM" == Nicolas Mailhot <nicolas.mailhot at 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.
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
More information about the devel