On Dec 27, 2015, at 8:29 AM, Michael Berkowski <[log in to unmask]> wrote:

>> How do I modify the permissions of a file under the supervision of SELunix
>> so the file can be executed as a CGI script?
>> 
>> I have two CGI scripts designed to do targeted crawls against remote
>> hosts. One script uses rsync on port 873 and the other uses wget on port
>> 443. I can run these scripts as me without any problems. None. They work
>> exactly as expected. But when the scripts are executed from my HTTP server
>> and under the user apache both rsync and wget fail. I have traced the
>> errors to some sort of permission problems generated from SELinux.
> 
> /usr/sbin/semanage and some other necessary things come from the package
> policycoreutils-python
> 
> By default, Apache is disallowed from making outbound network connections
> and there's an SELinux boolean to enable it (examples here
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-Booleans-Configuring_Booleans.html)
> 
> This is probably the most common thing anyone needs to change in SELinux.
> 
> $ setsebool -P httpd_can_network_connect on
> 
> (-P is to make it persist beyond reboots) As far as the wget, that setting
> alone may be enough to cure it, provided the  CGI script itself lives in a
> location Apache expects, which would already have the right context.
> Although both produce tcp errors, I'm not so certain it will also correct
> the rsync one.
> 
> To dig further, there are several actions you can take.
> 
> If something has the wrong context and you need to find out what the right
> context should be, you can list the relevant contexts along with the
> filesystem locations they're bound to with:
> 
> # list Apache-related contexts...
> $ semanage fcontext -l | grep httpd
> 
> You probably already know how to change one:
> 
> $ chcon -t new_context_name /path/to/file
> 
> It doesn't look like you got any denials related to CGI execution, so I
> would guess your scripts are where Apache expects them.
> 
> To list all Apache booleans and their states, use
> 
> $ getsebool -a | grep httpd
> 
> If you are unable to get your result using booleans or fixing the context,
> then you have to start digging into audit2allow. It will take denial lines
> from the audit log like those in your email from stdin and attempt to
> diagnose solutions with booleans, or help create a custom SELinux module to
> allow whatever you are attempting.
> 
> Start by grepping the relevant denied lines from /var/log/audit/audit.log,
> or get them from wherever you got the ones in your message. I usually put
> them into a file. Don't take every denial from the log, only the ones
> generated by the action you're trying to solve.
> 
> $ audit2allow < grepped_denials.txt
> 
> There may also be audit2why, but I don't know if CentOS6 has it and I've
> never used it.
> 
> Not sure if CentOS 6 has the updated tools which actually suggest booleans
> you can modify to fix denials, but if it does, you would get output like:
> 
> #============= httpd_t ==============
> 
> #!!!! This avc can be allowed using the boolean 'httpd_run_stickshift'
> allow httpd_t self:capability fowner;
> 
> #!!!! This avc can be allowed using the boolean 'httpd_execmem'
> allow httpd_t self:process execmem;
> 
> 
> If there are no booleans to modify, audit2allow will output policy
> configuration which would enable your action. Your last resort is to create
> a custom SELinux module with the -M flag that implements that policy.
> 
> # generate the module
> $ audit2allow -M YOURMODULENAME < grepped_denials.txt
> 
> Then you have to install the module
> 
> $ semodule -i YOURMODULENAME.pp
> 
> There may simpler ways of going about the module creation, but I do it so
> infrequently and this is the method I'm accustomed to. Red Hat has some
> docs here:
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-Fixing_Problems-Allowing_Access_audit2allow.html
> 
> So, I hope this gets you somewhere useful. In the best case scenario, you
> should only need to enable httpd_can_network_connect.
> 
> — 
> Michael Berkowski
> University of Minnesota Libraries


Michael, resolved, and thank you for the prompt and thorough reply.

Yes, SELinux was doing its job, and it was configured to disallow network connections from httpd. After issuing the following command (which allows httpd to make network connections) both my rsync- and wget-based CGI scripts worked without modification:

  setsebool http_can_network_connect on

Maybe I’ll add the -P option later. Yippie! Thank you. 

— 
Eric Lease Morgan