Hi everybody,
while the whole "bash"-storm is gaining force is it reasonable to develop SELinux policy prohibiting bash invocations from daemons' contexts to have access to anything but a tiny sandbox? Has anybody attempted such thing?
On 09/25/2014 01:37 PM, Dmitry Makovey wrote:
Hi everybody,
while the whole "bash"-storm is gaining force is it reasonable to develop SELinux policy prohibiting bash invocations from daemons' contexts to have access to anything but a tiny sandbox? Has anybody attempted such thing?
No SELinux would already block the bash exploit.
SELinux allows a process to do its stuff based on its type. Just because I can infect a bash script to attempt to do some bad access does not mean SELinux will not block it.
If I have a bash script running as httpd_t or mysqld_t and it gets hacked it would still only be allowed to do the things that mysqld_t or httpd_t can do.
It would block a cgi script launched from httpd_t from reading the mysqld database even if the mysqld database was world readable.
This is what SELinux does.
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
On 09/25/2014 02:14 PM, Daniel J Walsh wrote:
On 09/25/2014 01:37 PM, Dmitry Makovey wrote:
Hi everybody,
while the whole "bash"-storm is gaining force is it reasonable to develop SELinux policy prohibiting bash invocations from daemons' contexts to have access to anything but a tiny sandbox? Has anybody attempted such thing?
No SELinux would already block the bash exploit.
SELinux allows a process to do its stuff based on its type. Just because I can infect a bash script to attempt to do some bad access does not mean SELinux will not block it.
If I have a bash script running as httpd_t or mysqld_t and it gets hacked it would still only be allowed to do the things that mysqld_t or httpd_t can do.
It would block a cgi script launched from httpd_t from reading the mysqld database even if the mysqld database was world readable.
This is what SELinux does.
thanks Dan. I've got that part and appreciate what I already got out of the box with SELinux, however I was wondering if that containment can be furthered, saying that bash invoked in httpd_t should have even stricter policy applied? Possibly switch context to something that is very-very limited, to avoid things like :
http://www.reddit.com/r/netsec/comments/2hbxtc/cve20146271_remote_code_execu...
?
On 09/25/2014 04:24 PM, Dmitry Makovey wrote:
On 09/25/2014 02:14 PM, Daniel J Walsh wrote:
On 09/25/2014 01:37 PM, Dmitry Makovey wrote:
Hi everybody,
while the whole "bash"-storm is gaining force is it reasonable to develop SELinux policy prohibiting bash invocations from daemons' contexts to have access to anything but a tiny sandbox? Has anybody attempted such thing?
No SELinux would already block the bash exploit.
SELinux allows a process to do its stuff based on its type. Just because I can infect a bash script to attempt to do some bad access does not mean SELinux will not block it.
If I have a bash script running as httpd_t or mysqld_t and it gets hacked it would still only be allowed to do the things that mysqld_t or httpd_t can do.
It would block a cgi script launched from httpd_t from reading the mysqld database even if the mysqld database was world readable.
This is what SELinux does.
thanks Dan. I've got that part and appreciate what I already got out of the box with SELinux, however I was wondering if that containment can be furthered, saying that bash invoked in httpd_t should have even stricter policy applied? Possibly switch context to something that is very-very limited, to avoid things like :
http://www.reddit.com/r/netsec/comments/2hbxtc/cve20146271_remote_code_execu...
?
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
Looking at the example in this redit, httpd_t would be executing a script labeled httpd_sys_script_exec_t, which would transition to httpd_sys_script_t.
Which is what was expected.
The httpd_sys_script_t is a somewhat restricted policy. In that most of apache config, logs /var/lib etc is blocked. By default content in users homedirs, databases etc is all blocked.
Here are the types of files that httpd_sys_script_t is allowed to open and read on my rawhide system.
allow domain locale_t : file { ioctl read getattr lock open } ; allow httpd_sys_script_t iso9660_t : file { ioctl read getattr lock open } ; allow httpd_sys_script_t httpd_sys_ra_content_t : file { ioctl read create getattr lock append open } ; allow httpd_sys_script_t httpd_sys_rw_content_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ; allow httpd_sys_script_t squirrelmail_spool_t : file { ioctl read getattr lock open } ; allow httpd_sys_script_t anon_inodefs_t : file { ioctl read write getattr lock append open } ; allow httpd_sys_script_t sysctl_kernel_t : file { ioctl read getattr lock open } ; allow domain base_ro_file_type : file { ioctl read getattr lock open } ; allow httpd_sys_script_t httpd_sys_script_t : file { ioctl read write getattr lock append open } ; allow nsswitch_domain cert_t : file { ioctl read getattr lock open } ; allow httpd_script_type etc_runtime_t : file { ioctl read getattr lock open } ; allow httpd_script_type fonts_cache_t : file { ioctl read getattr lock open } ; allow domain mandb_cache_t : file { ioctl read getattr lock open } ; allow domain abrt_t : file { ioctl read getattr lock open } ; allow domain man_t : file { ioctl read getattr lock open } ; allow domain sysctl_vm_overcommit_t : file { ioctl read getattr lock open } ; allow kernel_system_state_reader proc_t : file { ioctl read getattr lock open } ; allow nsswitch_domain passwd_file_t : file { ioctl read getattr lock open } ; allow nsswitch_domain sssd_public_t : file { ioctl read getattr lock open } ; allow domain cpu_online_t : file { ioctl read getattr lock open } ; allow httpd_script_type public_content_rw_t : file { ioctl read getattr lock open } ; allow nsswitch_domain etc_runtime_t : file { ioctl read getattr lock open } ; allow nsswitch_domain hostname_etc_t : file { ioctl read getattr lock open } ; allow domain ld_so_cache_t : file { ioctl read getattr lock open } ; allow nsswitch_domain sssd_var_lib_t : file { ioctl read getattr lock open } ; allow httpd_script_type public_content_t : file { ioctl read getattr lock open } ; allow nsswitch_domain krb5_conf_t : file { ioctl read getattr lock open } ; allow domain abrt_var_run_t : file { ioctl read getattr lock open } ; allow httpd_sys_script_t httpd_tmp_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ; allow domain machineid_t : file { ioctl read getattr lock open } ; allow httpd_sys_script_t mysqld_etc_t : file { ioctl read getattr lock open } ; allow domain rpm_script_tmp_t : file { ioctl read getattr lock open } ; allow nsswitch_domain samba_var_t : file { ioctl read getattr lock open } ; allow domain sysctl_crypto_t : file { ioctl read getattr lock open } ; allow nsswitch_domain net_conf_t : file { ioctl read getattr lock open } ; allow httpd_script_type fonts_t : file { ioctl read getattr lock open } ; allow nsswitch_domain file_context_t : file { ioctl read getattr lock open } ; allow httpd_sys_script_t httpd_squirrelmail_t : file { ioctl read getattr lock append open } ; allow httpd_sys_script_t snmpd_var_lib_t : file { ioctl read getattr lock open } ; allow nsswitch_domain samba_etc_t : file { ioctl read getattr lock open } ; allow domain man_cache_t : file { ioctl read getattr lock open } ; allow nsswitch_domain etc_t : file { ioctl read getattr lock open } ; ET allow nsswitch_domain cert_t : file { ioctl read getattr lock open } ; [ authlogin_nsswitch_use_ldap ] ET allow nsswitch_domain slapd_cert_t : file { ioctl read getattr lock open } ; [ authlogin_nsswitch_use_ldap ] ET allow nsswitch_domain net_conf_t : file { ioctl read getattr lock open } ; [ authlogin_nsswitch_use_ldap ] ET allow domain sysctl_kernel_t : file { ioctl read getattr lock open } ; [ fips_mode ]
Allowed to read /etc/passwd which could be a problem and apache content, but a whole lot of stuff is blocked.
On 09/25/2014 02:44 PM, Daniel J Walsh wrote:
On 09/25/2014 04:24 PM, Dmitry Makovey wrote:
On 09/25/2014 02:14 PM, Daniel J Walsh wrote: thanks Dan. I've got that part and appreciate what I already got out of the box with SELinux, however I was wondering if that containment can be furthered, saying that bash invoked in httpd_t should have even stricter policy applied? Possibly switch context to something that is very-very limited, to avoid things like :
http://www.reddit.com/r/netsec/comments/2hbxtc/cve20146271_remote_code_execu...
Looking at the example in this redit, httpd_t would be executing a script labeled httpd_sys_script_exec_t, which would transition to httpd_sys_script_t.
Which is what was expected.
The httpd_sys_script_t is a somewhat restricted policy. In that most of apache config, logs /var/lib etc is blocked. By default content in users homedirs, databases etc is all blocked.
Here are the types of files that httpd_sys_script_t is allowed to open and read on my rawhide system.
....
Allowed to read /etc/passwd which could be a problem and apache content, but a whole lot of stuff is blocked.
thanks Dan, this clarifies a lot without having to go through the code/transitions manually :)
selinux@lists.fedoraproject.org