I have freshly installed CentOS 4 box, with Apache installed. I''ve
placed some CGI programs into /var/www/cgi-bin, however SELinux is
preventing the execution. One program is statically linked executable,
and the other is shell script.
It seems that everything has correct context:
Output of ls -Z for relevant files/directories looks like this. All
files and directories are user/group root:root, mode 755. Looks like it
should work:
system_u:object_r:httpd_exec_t /usr/sbin/httpd
system_u:object_r:httpd_sys_script_exec_t /var/www/cgi-bin
root:object_r:httpd_sys_script_exec_t /var/www/cgi-bin/compiled-exe.cgi
root:object_r:httpd_sys_script_exec_t /var/www/cgi-bin/sehll-script.sh
However, when Apache attempts to run any of them, I''m getting this
error
messages logged in /var/log/messages:
kernel: audit(1110396095.427:0): avc: denied { execute_no_trans } for
pid=1234 exe=/usr/sbin/httpd path=/var/www/cgi-bin/compiled-exe.cgi
dev=dm-1 ino=12345 scontext=user_u:system_r:httpd_t
tcontext=root:object_r:httpd_sys_script_exec_t tclass=file
Same thing if I try it out from command line.
I''ve Googled around, and was not able to find anything helpful. All I
was able to find were pointers telling me to set the security context of
files the way it is already set up.
--
Aleksandar Milivojevic <amilivojevic@pbl.ca> Pollard Banknote Limited
Systems Administrator 1499 Buffalo Place
Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7
> -----Original Message----- > From: centos-bounces@caosity.org [mailto:centos-bounces@caosity.org]On> Behalf Of Aleksandar Milivojevic > Sent: Wednesday, March 09, 2005 1:34 PM > To: CentOS Mailing List > Subject: [Centos] cgi trouble with apache and selinux > > I have freshly installed CentOS 4 box, with Apache installed. I''ve > placed some CGI programs into /var/www/cgi-bin, however SELinux is > preventing the execution. One program is statically linkedexecutable,> and the other is shell script. > > It seems that everything has correct context: > > Output of ls -Z for relevant files/directories looks like this. All > files and directories are user/group root:root, mode 755. Looks likeit> should work: > > system_u:object_r:httpd_exec_t /usr/sbin/httpd > system_u:object_r:httpd_sys_script_exec_t /var/www/cgi-bin > root:object_r:httpd_sys_script_exec_t/var/www/cgi-bin/compiled-exe.cgi> root:object_r:httpd_sys_script_exec_t /var/www/cgi-bin/sehll-script.sh > > However, when Apache attempts to run any of them, I''m getting thiserror> messages logged in /var/log/messages: > > kernel: audit(1110396095.427:0): avc: denied { execute_no_trans }for> pid=1234 exe=/usr/sbin/httpd path=/var/www/cgi-bin/compiled-exe.cgi > dev=dm-1 ino=12345 scontext=user_u:system_r:httpd_t > tcontext=root:object_r:httpd_sys_script_exec_t tclass=file > > Same thing if I try it out from command line. > > I''ve Googled around, and was not able to find anything helpful. All I > was able to find were pointers telling me to set the security contextof> files the way it is already set up.http://64.233.179.104/search?q=cache:GSBUHNeDQTkJ:fedora.redhat.com/docs /selinux-apache-fc3/+selinux+apache+cgi&hl=en http://64.233.179.104/search?q=cache:RbbHexbLOtEJ:www.fedoraforum.org/fo rum/archive/index.php/t-41377.html+selinux+apache+cgi&hl=en hth, Marc
Try running ''setsebool httpd_enable_cgi true'' as root. This should fix it. You may also want to check out http://fedora.redhat.com/docs/selinux-apache-fc3/ as it has some good documentation. I assume RHEL4 has some selinux docs as well, but I haven''t read through them yet. -- Jim Perrin Arbelos Systems On Wed, 09 Mar 2005 13:34:03 -0600, Aleksandar Milivojevic <amilivojevic@pbl.ca> wrote:> I have freshly installed CentOS 4 box, with Apache installed. I''ve > placed some CGI programs into /var/www/cgi-bin, however SELinux is > preventing the execution. One program is statically linked executable, > and the other is shell script. > > It seems that everything has correct context: > > Output of ls -Z for relevant files/directories looks like this. All > files and directories are user/group root:root, mode 755. Looks like it > should work: > > system_u:object_r:httpd_exec_t /usr/sbin/httpd > system_u:object_r:httpd_sys_script_exec_t /var/www/cgi-bin > root:object_r:httpd_sys_script_exec_t /var/www/cgi-bin/compiled-exe.cgi > root:object_r:httpd_sys_script_exec_t /var/www/cgi-bin/sehll-script.sh > > However, when Apache attempts to run any of them, I''m getting this error > messages logged in /var/log/messages: > > kernel: audit(1110396095.427:0): avc: denied { execute_no_trans } for > pid=1234 exe=/usr/sbin/httpd path=/var/www/cgi-bin/compiled-exe.cgi > dev=dm-1 ino=12345 scontext=user_u:system_r:httpd_t > tcontext=root:object_r:httpd_sys_script_exec_t tclass=file > > Same thing if I try it out from command line. > > I''ve Googled around, and was not able to find anything helpful. All I > was able to find were pointers telling me to set the security context of > files the way it is already set up. > > -- > Aleksandar Milivojevic <amilivojevic@pbl.ca> Pollard Banknote Limited > Systems Administrator 1499 Buffalo Place > Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7 > _______________________________________________ > CentOS mailing list > CentOS@caosity.org > http://lists.caosity.org/mailman/listinfo/centos >
Jim Perrin wrote:> Try running ''setsebool httpd_enable_cgi true'' > as root. This should fix it. > You may also want to check out http://fedora.redhat.com/docs/selinux-apache-fc3/ > as it has some good documentation. I assume RHEL4 has some selinux > docs as well, but I haven''t read through them yet.I''ve checked httpd_enable_cgi boolean, and it was at its default value (enabled): # grep httpd_enable_cgi /etc/selinux/targeted/booleans httpd_enable_cgi=1 # getsebool httpd_enable_cgi httpd_enable_cgi --> active Checked the document you and Marc were reffering to, and couldn''t find anything different in my configuration from what was described in that document. Running audit2allow on /var/log/messages produced this output: # audit2allow -i /var/log/messages -l allow httpd_t httpd_sys_script_exec_t:file execute_no_trans; Looking into the source for targeted policy it seems as this is not enabled. Bug in targeted policy rules? Anyhow, I''ve tried to add similar line to macros/program/apache_macros.te file, just after similar line for r_dir_perms: allow httpd_t httpd_$1_script_exec_t:file execute_no_trans; And did "make realod". After doing this, execution of CGI scripts seems to be working. The shell script CGI run fine, there was one ioctl blocked by SELinux. For compiled CGI, I need to enable it to read couple of files from the system first, but it seems to be working. -- Aleksandar Milivojevic <amilivojevic@pbl.ca> Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7
> Running audit2allow on /var/log/messages produced this output: > # audit2allow -i /var/log/messages -l > allow httpd_t httpd_sys_script_exec_t:file execute_no_trans; > Looking into the source for targeted policy it seems as this is not > enabled. Bug in targeted policy rules?Not necessarily. execute_no_tran means that you can execute a binary belong to another domain without transition (domain).> Anyhow, I''ve tried to add similar line to > macros/program/apache_macros.te file, just after similar line forit would be better to create a local.te under misc. Because of upgrades and cleaner system.> blocked by SELinux. For compiled CGI, I need to enable it to read > couple of files from the system first, but it seems to be working.run apol to ensure that you don''t weaken your system. bye, Ago
ago@lsc.hu wrote:>>Looking into the source for targeted policy it seems as this is not >>enabled. Bug in targeted policy rules? > > Not necessarily. execute_no_tran means that you can execute a binary > belong to another domain without transition (domain). > >>Anyhow, I''ve tried to add similar line to >>macros/program/apache_macros.te file, just after similar line for > > it would be better to create a local.te under misc. Because of upgrades > and cleaner system. > >>blocked by SELinux. For compiled CGI, I need to enable it to read >>couple of files from the system first, but it seems to be working. > > run apol to ensure that you don''t weaken your system.Thanks for the all of the above hints. I''m still relatively new to SELinux, and still discovering things. For now it is mostly "OK, this doesn''t work, how to get it to work quickly". I''m planning to dive into it more as time permits... Anyhow, I still don''t see why CGI scripts/programs were not working out of the box when placed in /var/www/cgi-bin. This box is fresh install with almost default configuration. I tought targeted policy should allow that by default (provided httpd_enable_cgi is set to true, which seems to be default setting)? Am I the only one with this problem? I have a separate partition for /var, mounted with nosuid flag, which might or might not make my system a bit different, however I don''t see how this should affect SELinux policy (acutally, once this gets solved completely, I''ll be moving cgi-bin to /usr, and mounting /var with noexec,nosuid). Related to this, when I attempted to use mod_suexec in httpd.conf (something along the lines of "SuexecUserGroup apache apache", which should be user scritps run if suexec is not used), I got more SELinux related errors in /var/log/messages... I found apol utility (/usr/share/setools/apol.tcl), however it seems to require awish, that i don''t have installed. Running it in normal wish results in error message saying that I need Tk with BWidgets compiled in... What package do I need for awish? -- Aleksandar Milivojevic <amilivojevic@pbl.ca> Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7
On Thu, 10 Mar 2005 09:23:19 -0600, Aleksandar Milivojevic <amilivojevic@pbl.ca> wrote:> Anyhow, I still don''t see why CGI scripts/programs were not > working out of the box when placed in /var/www/cgi-bin. This box > is fresh install with almost default configuration. I tought > targeted > policy should allow that by default (provided > httpd_enable_cgi is set to true, which seems to be default > setting)? Am I the only one with this problem?Because enabling httpd to run cgi processes presents a potential security risk that should be expressly taken rather than left to the system administrator to realize and secure after the fact? This was (is?) one of the great problems with Microsoft products, everything is turned on by default so that Microsoft can avoid the support costs of guiding users through what they can safely enable. The excuse given is that people responsible for systems should "know" what to turn off to establish whatever level of security they are most comfortable with. Human nature being what it is, if some process you need does not work then you will be compelled to discover how to enable it. If you do not need it then it does not need to be enabled and probably should not be. This is by far the best way to avoid those embarrassing "gotchas" that the less reputable seek to exploit. Security is always best served on a "need to" only basis. Regards, Jim -- *** e-mail is not a secure channel *** mailto:byrnejb.<token>@harte-lyne.ca James B. Byrne Harte & Lyne Limited vox: +1 905 561 1241 9 Brockley Drive fax: +1 905 561 0757 Hamilton, Ontario <token> = hal Canada L8E 3C3
Quoting "James B. Byrne" <ByrneJB@Harte-Lyne.ca> Date: Thu, 10 Mar 2005 12:39:17> Because enabling httpd to run cgi processes presents a potential > security risk that should be expressly taken rather than left to > the system administrator to realize and secure after the fact?I totaly agree what you wrote (both qouted, and not quoted parts of your email). However, there is one big "however" to consider. If you are forcing users to jump through too many hops to get something working, they are more likely to disable security mechanisms than to configure things correctly. This is not limited to IT security. It is in human nature. Look at the recent email from Cristofer on this mailing list. What was the first thing he did? Disable SELinux. Search the forums for this kind of problems. I did (and still do, since problem is not solved), and what I found was that most advice boils down to: it is because of SELinux, just disable it and things will work. Go to Fedora mailing list. Every week there is at least one new thread on topic "is SELinux worth the trouble or should I just disable the bugger during the install". What this boils down to is, if you have security mechanism that is too complex or too hard to configure, nobody will use it. Same goes for the systme that is too noisy (too many false positives). So you are at the same level as not having it at all. Because people are going to disable it routinely at the first opportunity they have. This is the single biggest mistake security professionals make on regular basis. Ignoring human nature. Thinking that technology itself can solve security problems. It can''t. The human nature must be part of the system. Or system will not function as intended, or not function at all. This is not some wisdom I just invented. It took some time even for big names such as Bruce Schneier to realize this. He wrote openly about the path he went in his later works. To get back to the problem I have. I went through all documentation, did everything by the book. And things do not work. What can I do now. The choices are disabling SELinux or risking being real late with the project that is by itself rather simple in nature (couple of more or less trivial CGI scripts). -- Aleksandar Milivojevic <amilivojevic@pbl.ca> Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7
On 10 Mar 2005 at 22:06, Aleksandar Milivojevic wrote:> If you are forcing users to jump through too many hops to get > something working, they are more likely to disable security > mechanisms than to configure things correctly. This is not > limited to IT security. It is in human nature.Yes, this is one of the great problems of automated computing since its inception, the lack of consistency in approach to human interface solutions and the arcane complexity in consequence of having many single-purpose solutions required to interact with one another. These aspects of Unix and Linux are oft depreciated examples frequently used in arguments of why heterogeneous development (open source) is not yet ready for "prime time." I find myself spending far more time pouring over manuals, how-to books and articles, READMES, and even source code, trying to discover why program xyz will not run or produce the expected result than I spend creating code or designing systems. For example, I am in the process of moving our imap server from an RH 3ES box to a newly built CentOS 4 platform. Now on RH3 I had to get Dag''s Cyrus-Imapd and install it, and poke around for a bit with saslauth and after seven or ten days of trial and error I completed the move from our old HP-UX machine to RH. That was last year. Now I am moving from RH3 to CentOS 4 and mercy of mercies, Cyrus- Imapd is shipped with CentOS4. What could be simpler? Well, despite the fact that I am just doing a proof of concept test and am simply using basic Linux authentication right out of the box, I am not yet able to connect as the cyrus user and create mailboxes. Admittedly I only started this yesterday afternoon but still, one would think that the basic configuration would just "go" when one fired up the daemons and not require a considerable effort to find out which packager assumptions I am transgressing because another packager''s assumptions do not coincide with the first''s. This situation is very frustrating but it must be kept in perspective. I recall building my first Cyrus-Imap server back in October of 1995 and having first to get and bootstrap build binutils and gcc with the K&R C compiler HP shipped and only then locate, download, and build, often after considerable heartache discovering which modifications were necessary to successfully compile, each of many support systems necessary to get what I wanted, a sealed server mailbox solution, running. By comparison to then the improvement in the present situation is almost surreal. I expect that package management will further advance to also deal with the annoying aspect of package configuration, automatically detecting existing installations and logically reconfiguring the new package to co-operatively work with the existing software. Something like the Microsoft Windows registry, in function and intent, will be the next logical step in Linux package management and configuration. A well defined package configuration API consistently applied will go a long way to simplifying Linux system administration and improving productivity. SELinux will possibly hasten that development because of its fine granularity which offers the prospect of nearly infinite torture if something obscure goes wrong. Back to saslauth. Regards, Jim -- *** e-mail is not a secure channel *** mailto:byrnejb.<token>@harte-lyne.ca James B. Byrne Harte & Lyne Limited vox: +1 905 561 1241 9 Brockley Drive fax: +1 905 561 0757 Hamilton, Ontario <token> = hal Canada L8E 3C3
Aleksandar Milivojevic
2005-Mar-11 19:40 UTC
[Centos] SOLVED: cgi trouble with apache and selinux
Aleksandar Milivojevic wrote:> I have freshly installed CentOS 4 box, with Apache installed. I''ve > placed some CGI programs into /var/www/cgi-bin, however SELinux is > preventing the execution. One program is statically linked executable, > and the other is shell script.Please see full thread for complete details and full description of problem. I''ve placed this problem on RHEL4 Bugzilla, and got an answer that solved the problem completely: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=150880 The problem with my configuration was that /var was mounted with nosuid flag: /dev/system_vg/var_vol /var ext3 nosuid 1 2 When partition is mounted nosuid, domain transitions are not possible. Effectively this prevents CGI scripts from running. Mounting partition with suid flag (default) solved the problem: /dev/system_vg/var_vol /var ext3 defaults 1 2 So to summarize. To be able to run CGI programs under SELinux using targeted policy: 1. Apache should run under httpd_t type. 2. CGI executable security context should include httpd_sys_script_exec_t. 3. httpd_enable_cgi SELinux boolean must be set to true (or 1). 4. Partition where CGI executable is located must be mounted with suid flag (default). IMO, good practice would be moving cgi-bin directory to partition such as /usr, that could be mounted with ro (read-only) flag, and needs suid and exec flags anyhow. That way, /var (that contains files/directories writtable by Apache) can be mounted with rw,nosuid,noexec flags. I wish to thank everyone for the feedback I got, and their time and effort. Special thanks to Colin Walters of Red Hat for pointing effects of nosuid/suid mount flag on SELinux policies. -- Aleksandar Milivojevic <amilivojevic@pbl.ca> Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7