Hi Eric,
/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
On Sat, Dec 26, 2015 at 7:20 PM, Eric Lease Morgan <[log in to unmask]> wrote:
> On Dec 26, 2015, at 8:14 PM, Childs, Riley <[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.
> >> Specifically, SELinux generates the following errors for the rsync
> script:
> >>
> >> type=AVC msg=audit(1450984068.685:19667): avc: denied {
> >> name_connect } for pid=11826 comm="rsync" dest=873
> >> scontext=unconfined_u:system_r:httpd_sys_script_t:s0
> >> tcontext=system_u:object_r:rsync_port_t:s0 tclass=tcp_socket
> >>
> >> type=SYSCALL msg=audit(1450984068.685:19667): arch=c000003e
> >> syscall=42 success=no exit=-13 a0=3 a1=1b3c030 a2=10
> >> a3=7fffb057acc0 items=0 ppid=11824 pid=11826 auid=500 uid=48
> >> gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48
> >> tty=(none) ses=165 comm="rsync" exe="/usr/bin/rsync"
> >> subj=unconfined_u:system_r:httpd_sys_script_t:s0 key=(null)
> >>
> >> SELinux generates these errors for the wget script:
> >>
> >> type=AVC msg=audit(1450984510.396:19715): avc: denied {
> >> name_connect } for pid=13263 comm="wget" dest=443
> >> scontext=unconfined_u:system_r:httpd_sys_script_t:s0
> >> tcontext=system_u:object_r:http_port_t:s0 tclass=tcp_socket
> >>
> >> type=SYSCALL msg=audit(1450984510.396:19715): arch=c000003e
> >> syscall=42 success=no exit=-13 a0=4 a1=7ffe1d05b890 a2=10
> >> a3=7ffe1d05b4f0 items=0 ppid=13219 pid=13263 auid=500 uid=48
> >> gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48
> >> tty=(none) ses=165 comm="wget" exe="/usr/bin/wget"
> >> subj=unconfined_u:system_r:httpd_sys_script_t:s0 key=(null)
> >>
> >> How do I diagnose these errors? Do I need to use something like chcon to
> >> change my CGI scripts’ permissions? Maybe I need to use chcon to change
> >> rsync’s or wget’s permissions? Maybe I need to use something like
> semanage
> >> (which doesn’t exist on my system) to change the user apache’s
> permissions
> >
> > SELinux :) Which distro are you running?
>
> I am running CentOS release 6.7. —ELM
>
