?

Log in

No account? Create an account

Previous Entry Share Next Entry
A follow up to the Bash Exploit and SELinux.
danwalsh
One of the advantages of a remote exploit is to be able to setup and launch attacks on other machines.

I wondered if it would be possible to setup a bot net attack using the remote attach on an apache server with the bash exploit.

Looking at my rawhide machine's policy

sesearch -A -s httpd_sys_script_t -p name_connect -C | grep -v ^D
Found 24 semantic av rules:
   allow nsswitch_domain dns_port_t : tcp_socket { recv_msg send_msg name_connect } ;
   allow nsswitch_domain dnssec_port_t : tcp_socket name_connect ;
ET allow nsswitch_domain ldap_port_t : tcp_socket { recv_msg send_msg name_connect } ; [ authlogin_nsswitch_use_ldap ]


The apache script would only be allowed to connect/attack a dns server and an LDAP server.  It would not be allowed to become a spam bot (No connection to mail ports) or even attack other web service.

Could an attacker leave a back door to be later connected to even after the bash exploit is fixed?

# sesearch -A -s httpd_sys_script_t -p name_bind -C | grep -v ^D
#

Nope!  On my box the httpd_sys_script_t process is not allowed to listen on any network ports.

I guess the crackers will just have to find a machine with SELinux disabled.

  • 1

Kind of offtopic but still SElinux related

Hello, Dan!

I am sorry to address you here and not in bugzilla, but I am not sure if what I've ran into is a bug - so writing here. Would you please give me a hint how to resolve the following SElinux related problem?

I need to allow write permission for the directory via ftp (web developer needs that).

Here is what I have:

CentOS Linux release 7.0.1406 (Core)
selinux-policy-targeted-3.12.1-153.el7_0.13.noarch
nginx-1.7.10-1.el7.ngx.x86_64
vsftpd-3.0.2-9.el7.x86_64

Currently the permissions and context is the following:

# ls -dZ /var/www/html/dver/public/
drwxrwxr-x. nginx nginx system_u:object_r:httpd_sys_rw_content_t:s0 /var/www/html/dver/public/

# getsebool -a | grep ftpd
ftpd_anon_write --> off
ftpd_connect_all_unreserved --> off
ftpd_connect_db --> off
ftpd_full_access --> on
ftpd_use_cifs --> off
ftpd_use_fusefs --> off
ftpd_use_nfs --> off
ftpd_use_passive_mode --> off
sftpd_anon_write --> off
sftpd_enable_homedirs --> off
sftpd_full_access --> off
sftpd_write_ssh_home --> off

Everything is fine, directory is writeable. But I do not like the 'ftpd_full_access --> on' situation. I cannot assess the possible danger of having it enabled though. If it is OK - then my question is renedered null and void :)

So what I tried to do is to set the context of directory in question to 'public_content_rw_t' and disable 'ftpd_full_access'. According to manual, 'public_content_rw_t' is OK to use both for ftp and web server. But after doing so everything was broken - here is the log and audit2why output:

# cat audit.log | audit2why
type=AVC msg=audit(1427205840.506:111500): avc: denied { write } for pid=12169 comm="vsftpd" name="public" dev="vda2" ino=916858 scontext=system_u:system_r:ftpd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:public_content_rw_t:s0 tclass=dir

Was caused by:
Unknown - would be allowed by active policy
Possible mismatch between this policy and the one under which the audit message was generated.

Possible mismatch between current in-memory boolean settings vs. permanent ones.

type=AVC msg=audit(1427205893.039:111510): avc: denied { write } for pid=12190 comm="vsftpd" name="public" dev="vda2" ino=916858 scontext=system_u:system_r:ftpd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:public_content_rw_t:s0 tclass=dir

Was caused by:
Unknown - would be allowed by active policy
Possible mismatch between this policy and the one under which the audit message was generated.

Possible mismatch between current in-memory boolean settings vs. permanent ones.

So I had to set everything back to 'httpd_sys_rw_content_t' and 'ftpd_full_access --> on' but still in doubt why it throws the error like that with 'public_content_rw_t' and disabled 'ftpd_full_access'...

I appreciate your reply.

Re: Kind of offtopic but still SElinux related

Set it to public_content_rw_t and ftpd_anon_write should work.

  • 1