Apache CGI scripts - how to run them cleanly

[Dominick Grift]

On Tue, May 04, 2010 at 04:16:28PM -0700, Lars Poulsen wrote:
> At 01:16 PM 5/4/2010, Dominick Grift wrote:
> >First i would like to say that i would not host websites from /home/*.
> 
> In my first message in this thread I gave some background and
> explained why I was doing this. I REALLY do not want content to live
> in my root partition; I want to be free to wipe the root partition
> when I do a version upgrade on the operating system (once per year
> or so).
> 
> >Secondly, you should use the semanage plus fcontext option to make
> >your file context specifications persistent.
> 
> When I am all done with the process of making my system work
> (understanding what the things are than can be tuned under the
> "targeted" policy, my next project may well be to learn how to make
> my own tweaks to policy in a way that is compatible across updates
> to the system policies. Right now, that seems to be several levels
> up on my learning curve. Despite 20 years of working part time with
> *nix system administration (my first Unix experience was on a
> version 7 unix with BBN's ARPAnet patches) I am still struggling
> with all the "new" stuff, including SELinux.
> 
> While it may be a good thing to tweak filecontexts with semanage, it
> seems to me that minor tweaks like this should be perfectly fine to
> make "permanent" by invoking them from a file that is included from
> /etc/rc.local at startup time. If I do "permanent" changes
> interactively from the command line, it becomes hard to keep track
> of them so they can be done again afgter a system version upgrade.
> 
> >But i you want to use /home/* to host websites then i guess
> >httpd_sys_content_t would be a good type for its webroot like it
> >is for /var/www.
> >The issue here is that a directory at inode # 2 on device dm-7 is
> >labeled user_home_dir_t and that the httpd_sys_script_t domain is
> >not allowed to read it.
> 
> One of the sub-problems here is that I really do not know what
> device "dm-7" is. /home is mounted on a "partition" created by LVM
> (Logical Volume Manager). On a "df" command or a "mount" display it
> shows up as /dev/mapper/VolGroup00-SystemHome. I am guessing it is
> the same.
> 
> But ls -Zd /home gives the label as  system_u:object_r:home_root_t:s0
> Is it possible that ls -Z and SELinux (runtime) have different
> notions of what is in the inode ?
> 
> >Either you allow it or you label the dir at inode 2 on dm-7 with a
> >type that apache can search.
> 
> Other than by tweaking the label, how could I allow it ?
> And what are the types that apache can search ?
> Is there a list of them in a file in the source RPM for policy-targeted ?
> Is a user expected to recompile the policy or even read the source ?
> Is there a manual with this information ?

Either label the target in this operation with a type that source can access. You can use the sesearch command to find out:

sesearch -SC --allow -s httpd_sys_script_t -c dir -p search

or use audit2allow command to allow the AVC denial (man audit2allow)

ausearch -m avc -ts today | grep httpd_sys_script_t | grep search | audit2allow -M myhttpd; semodule -i myhttpd.pp

hth

> 
> I have been doing lots of googling for pages that might contain
> information about this stuff, but without much success. I did find
> http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:_Ch20_:_The_Apache_Web_Server
> which was quite useful (section "Security Contexts For CGI
> Scripts"), but I still do not understand why apache would need
> "search" access (does that mean directory read operations ?) for
> /home/ in order to launch a perl script located in
> /home/httpd/cgi-bin/.
> One article I read says this is actually a false error: The script
> will run just fine ev en if SELinux is enforcing, and it suggests
> you just use "noaudit" to suppress the denial messages about it.
> 
> Lars Poulsen
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/selinux/attachments/20100505/cb39b8bb/attachment.bin