Re: [CODE4LIB] selinux [resolved]

[Eric Lease Morgan]

On Dec 27, 2015, at 8:29 AM, Michael Berkowski  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

Re: [CODE4LIB] selinux

[Michael Berkowski]

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  wrote:

> On Dec 26, 2015, at 8:14 PM, Childs, Riley  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=c03e
> >>  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:
> >>
> >>  

Re: [CODE4LIB] selinux

[Eric Lease Morgan]

On Dec 26, 2015, at 8:14 PM, Childs, Riley  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=c03e
>>  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=c03e
>>  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

[CODE4LIB] selinux

[Eric Lease Morgan]

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=c03e
  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=c03e
  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?

This is a level of the operating system of which I am unfamiliar. 

— 
Eric Lease Morgan

Re: [CODE4LIB] selinux

[Childs, Riley]

SELinux :)
Which distro are you running?
On Dec 26, 2015 20:05, "Eric Lease Morgan"  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=c03e
>   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=c03e
>   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?
>
> This is a level of the operating system of which I am unfamiliar.
>
> —
> Eric Lease Morgan
>