I am trying to get my Fedora 12 systems to run cleanly with SELinux enabled. Previously I had just been running in permissive mode and mostly ignoring the alerts, but my ambition level has gone up!
After a few days of following up on every alert I saw by tweaking booleans and file context types appropriately, I am pleased with how few violations are being reported, but I am now getting to some that I cannot figure out, such as the one below.
It originates in a CGI script written in PERL. In my installations, the base of the website data is in /home/httpd rather than in /var/www; this choice is because I try to keep permanent data that should be kept across OS version updates out of the root filesystem, and the website is too small to merit a filesystem of its own. It does mean that I need to tweek a bunch of labels, such as * setsebool -P httpd_read_user_content 1 * setsebool -P httpd_enable_home_dirs 1 * setsebool -P httpd_read_user_content 1 * setsebool -P samba_enable_home_dirs 1 * setsebool -P use_samba_home_dirs 1 * setsebool -P samba_export_all_rw 1 * * chcon -R -t httpd_user_content_t /var/log/phone * chcon -R -t httpd_user_content_t /home/httpd/twiki/data * chcon -R -t httpd_sys_script_exec_t /home/httpd/twiki/bin * 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_homme_dir_t, should the boolean httpd_enable_home_dirs not make it allright ?
Any insights would be appreciated.
Lars Poulsen Afar Communications ------------------------------------------------------------------------------------------------------------------------- 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_u:object_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_u:object_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)
On Tue, May 04, 2010 at 12:03:28PM -0700, Lars Poulsen wrote:
I am trying to get my Fedora 12 systems to run cleanly with SELinux enabled. Previously I had just been running in permissive mode and mostly ignoring the alerts, but my ambition level has gone up!
After a few days of following up on every alert I saw by tweaking booleans and file context types appropriately, I am pleased with how few violations are being reported, but I am now getting to some that I cannot figure out, such as the one below.
It originates in a CGI script written in PERL. In my installations, the base of the website data is in /home/httpd rather than in /var/www; this choice is because I try to keep permanent data that should be kept across OS version updates out of the root filesystem, and the website is too small to merit a filesystem of its own. It does mean that I need to tweek a bunch of labels, such as * setsebool -P httpd_read_user_content 1 * setsebool -P httpd_enable_home_dirs 1 * setsebool -P httpd_read_user_content 1 * setsebool -P samba_enable_home_dirs 1 * setsebool -P use_samba_home_dirs 1 * setsebool -P samba_export_all_rw 1 * * chcon -R -t httpd_user_content_t /var/log/phone * chcon -R -t httpd_user_content_t /home/httpd/twiki/data * chcon -R -t httpd_sys_script_exec_t /home/httpd/twiki/bin * 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_homme_dir_t, should the boolean httpd_enable_home_dirs not make it allright ?
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
Any insights would be appreciated.
Lars Poulsen Afar Communications
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_u:object_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_u:object_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
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?
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_u:object_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_u:object_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
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_u:object_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_u:object_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
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 ?
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_A... 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
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_A... 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
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 ?
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_A... 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@lists.fedoraproject.org