FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora SELinux Support

 
 
LinkBack Thread Tools
 
Old 05-04-2010, 08:16 PM
Dominick Grift
 
Default Apache CGI scripts - how to run them cleanly

On Tue, May 04, 2010 at 12:51:24PM -0700, Lars Poulsen wrote:
>
> >On Tue, May 04, 2010 at 12:03:28PM -0700, Lars Poulsen wrote:
> >> * setsebool -P httpd_read_user_content 1
> >> * setsebool -P httpd_enable_home_dirs 1
> >> * setsebool -P httpd_read_user_content 1
> >> * ....
> >> * chcon -R -t httpd_sys_script_exec_t /home/httpd/cgi-bin
> >> * chcon -t httpd_sys_content_t /home/httpd
> >> * chcon -R -t httpd_sys_content_t /home/httpd/html
> >> * chcon -R -t httpd_user_content_t /home/sales/serial
> >> * chcon -R -t htppd_user_content_t /home/sales/leads
> >> But the one that baffles me the most is this one, which comes up when
> >> I trigger the CGI script /home/httpd/cgi-bin/serial.cgi (written in PERL).
> >>
> >> I *think* the "search" access is triggered when the script is launched.
> >> SELinux says that / is labeled as user_home_dir_t, but this is not
> >> true; ls -Zd confirms that it is indeed labeled as root_t. And even
> >> if it were labeled user_home_dir_t, should the boolean
> >> httpd_enable_home_dirs not make it allright ?
>
> At 12:21 PM 5/4/2010, Dominick Grift wrote:
> >Did you mount a seperate partition under /home or /home/*?
> >The AVC denial also show the device in question. It may in fact be
> >/ on the mounted partition and not your main /.
> >I think a restorecon -R /home or /home/* should solve it though
>
> Indeed, /home is a separate filesystem.
> ls -Zd tells me that /home is labeled home_root_t.
> As shown above, /home/httpd is labeled httpd_sys_content_t.
> What do you think is the "correct" label for them to allow them to
> house a CGI program?
>

First i would like to say that i would not host websites from /home/*.
Secondly, you should use the semanage plus fcontext option to make your file context specifications persistent.

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.

Either you allow it or you label the dir at inode 2 on dm-7 with a type that apache can search.

> Lars Poulsen
>
>
> >> -------------------------------------------------------------------------------------------------------------------------
> >> Summary:
> >>
> >> SELinux is preventing /usr/bin/perl "search" access to /.
> >>
> >> Detailed Description:
> >>
> >> [SELinux is in permissive mode. This access was not denied.]
> >>
> >> SELinux denied access requested by serial.cgi. / may be a
> >mislabeled. / default
> >> SELinux type is root_t, but its current type is user_home_dir_t.
> >Changing this
> >> file back to the default type, may fix your problem.
> >>
> >> File contexts can be assigned to a file in the following ways.
> >>
> >> * Files created in a directory receive the file context of the parent
> >> directory by default.
> >> * The SELinux policy might override the default label inherited from the
> >> parent directory by specifying a process running in context A
> >> which creates
> >> a file in a directory labeled B will instead create the
> >file with label C.
> >> An example of this would be the dhcp client running with the
> >> dhclient_t type
> >> and creating a file in the directory /etc. This file would
> >> normally receive
> >> the etc_t type due to parental inheritance but instead the
> >file is labeled
> >> with the net_conf_t type because the SELinux policy specifies this.
> >> * Users can change the file context on a file using tools
> >such as chcon, or
> >> restorecon.
> >>
> >> This file could have been mislabeled either by user error, or if
> >an normally
> >> confined application was run under the wrong domain.
> >>
> >> However, this might also indicate a bug in SELinux because the
> >file should not
> >> have been labeled with this type.
> >>
> >> If you believe this is a bug, please file a bug report against
> >this package.
> >>
> >> Allowing Access:
> >>
> >> You can restore the default system context to this file by executing the
> >> restorecon command. restorecon '/', if this file is a directory, you can
> >> recursively restore using restorecon -R '/'.
> >>
> >> Fix Command:
> >>
> >> /sbin/restorecon '/'
> >>
> >> Additional Information:
> >>
> >> Source Context system_u:system_r:httpd_sys_script_t:s0
> >> Target Context unconfined_ubject_r:user_home_dir_t:s0
> >> Target Objects / [ dir ]
> >> Source serial.cgi
> >> Source Path /usr/bin/perl
> >> Port <Unknown>
> >> Host shadow.afar.net
> >> Source RPM Packages perl-5.10.0-87.fc12
> >> Target RPM Packages filesystem-2.4.30-2.fc12
> >> Policy RPM selinux-policy-3.6.32-113.fc12
> >> Selinux Enabled True
> >> Policy Type targeted
> >> Enforcing Mode Permissive
> >> Plugin Name restorecon
> >> Host Name shadow.afar.net
> >> Platform Linux shadow.afar.net
> >2.6.32.11-99.fc12.i686.PAE
> >> #1 SMP Mon Apr 5 16:15:03 EDT 2010 i686 i686
> >> Alert Count 6
> >> First Seen Tue 04 May 2010 10:27:30 AM PDT
> >> Last Seen Tue 04 May 2010 11:15:28 AM PDT
> >> Local ID 6cee89bd-3559-4483-9802-fa2dc320bd26
> >> Line Numbers
> >>
> >> Raw Audit Messages
> >>
> >> node=shadow.afar.net type=AVC msg=audit(1272996928.152:22292):
> >> avc: denied { search } for pid=15632 comm="serial.cgi" name="/"
> >> dev=dm-7 ino=2 scontext=system_u:system_r:httpd_sys_script_t:s0
> >> tcontext=unconfined_ubject_r:user_home_dir_t:s0 tclass=dir
> >>
> >> node=shadow.afar.net type=SYSCALL msg=audit(1272996928.152:22292):
> >> arch=40000003 syscall=5 success=yes exit=3 a0=8b6767c a1=8000 a2=0
> >> a3=0 items=0 ppid=31549 pid=15632 auid=4294967295 uid=48 gid=489
> >> euid=48 suid=48 fsuid=48 egid=489 sgid=489 fsgid=489 tty=(none)
> >> ses=4294967295 comm="serial.cgi" exe="/usr/bin/perl"
> >> subj=system_u:system_r:httpd_sys_script_t:s0 key=(null)
> >>
> >> --
> >> selinux mailing list
> >> selinux@lists.fedoraproject.org
> >> https://admin.fedoraproject.org/mailman/listinfo/selinux
> >
> >
> >--
> >selinux mailing list
> >selinux@lists.fedoraproject.org
> >https://admin.fedoraproject.org/mailman/listinfo/selinux
>
--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
 
Old 05-04-2010, 11:16 PM
Lars Poulsen
 
Default Apache CGI scripts - how to run them cleanly

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_ubject_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 ?

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

--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
 
Old 05-05-2010, 08:20 AM
Dominick Grift
 
Default Apache CGI scripts - how to run them cleanly

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_ubject_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
>
--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
 
Old 05-05-2010, 08:22 AM
Dominick Grift
 
Default Apache CGI scripts - how to run them cleanly

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_ubject_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 ?

Yes, there is the Fedora (and RedHat) SELinux user guide (google)
and there is the Fedora (and RedHat) Managing Confined services guide (google)

>
> 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
>
--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
 

Thread Tools




All times are GMT. The time now is 06:33 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org