View Full Version : selinux denies httpd localhost access to virtualhosts
12th December 2010, 11:00 PM
I'm running a localhost development httpd (apache2) server on fc14, and I've pointed a virtualhost to a mounted ntfs volume. Selinux doesn't like this and denies access to the mounted volume which it has decided is the wrong kind of file system (without me going into details), so I have set selinux to permissive at the global level as a short-term workaround.
Is there a way to configure selinux to let apache2 have its way while still providing a modicum of protection against outside attacks (this is a workstation behind a firewalled broadband router, not a public-facing server).
12th December 2010, 11:14 PM
setsebool -P httpd_use_nfs on
... should allow httpd to use nfs but you'll lose some security features.
i suggest you read:
fedora managing confined services
fedora selinux user guide
13th December 2010, 01:47 AM
OK now I can't re-enable selinux (by changing /etc/selinux/config back to "SELINUX=enforcing") to test out your suggestion.
^^^ edit: I was able to restore to default and have tried applying your patch. I'll let you know if it didn't work, otherwise you may assume it does...
---------- Post added at 08:47 PM ---------- Previous post was at 07:21 PM ----------
Well it didn't work but further reading reveals why: I forgot to mention the mounted ntfs volume I am trying to point an apache2 virtualhost to is on the same machine, it isn't a network volume (nfs). The actual selinux error message is:
SELinux denied access requested by httpd. /mnt/apps may be a mislabeled.
/mnt/apps default SELinux type is mnt_t, but its current type is fusefs_t.
This (http://danwalsh.livejournal.com/28027.html?thread=198267) seems to point to a possible solution, but I'm not sure I'm up to working out the right syntax for my special case. Do you think you would be able to based on the info I've given? The volume is mounted by "ntfs-3g /dev/sda7 /mnt/apps"
13th December 2010, 09:12 AM
Try mounting it with the context= option (man mount). Use a context that best fits your requirements, example:
looks like you have mounted a fusefs on /mnt/apps, fusefs does not support extended attributes. By mounting it with context= and by using a type that fits youre requirements you can allow httpd (and maybe others) to interact with it without losing too much security.
Alternatively you could use audit2allow to generate a loadable policy module to allow httpd to interact with fusefs, but this is less desirable than mounting it with a context.
14th December 2010, 11:19 AM
To my way of thinking, this is a bug. When it gets fixed, I might consider using selinux again.
14th December 2010, 11:46 AM
It isn't a bug.
NTFS is not a secure file system. It is a user implemented and user labeled
filesystem (via fuse). As far as I know, it doesn't support security labels.
15th December 2010, 12:05 AM
Yeah. That may be. What I want is to allow my development, localhost web server untramelled access to anything I decide to point it at, whether it's an ntfs volume, a usb stick or a floppy disk (don't be unduly alarmed, the latter two are merely hypothetical examples).
If selinux doesn't allow me to do that, then selinux is useless to me.
It's a bit like putting a padlock on your oven door: very secure against people who would do nefarious things in your oven like, I dunno, bake stuff or dig tunnels into your bank, but rather inconvenient.
15th December 2010, 12:19 AM
If you want to be insecure. fine. go use windows.
After all, that is what NTFS is for.
16th December 2010, 01:24 AM
"security so powerful, don't bother turning on the pc"
16th December 2010, 02:04 AM
Security so powerful criminals stay away.
16th December 2010, 02:20 AM
All users are criminals...
Oh: Speaking of criminals, Any NSA backdoors we should know about?
16th December 2010, 02:23 AM
I guess you need to turn yourself in.
16th December 2010, 02:33 AM
Ever read any James Bamford? Didn't think so...
16th December 2010, 02:41 AM
Read Groklaw though.
vBulletin® v3.8.7, Copyright ©2000-2013, vBulletin Solutions, Inc.