Recent bash vulnerability and SELinux containment

[Dmitry Makovey]

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?

-- 
Dmitry Makovey
Web Systems Administrator
Athabasca University
[phone]
---
Confidence is what you have before you understand the problem
    Woody Allen

When in trouble when in doubt run in circles scream and shout
     http://www.wordwizard.com/phpbb3/viewtopic.php?f=16&t=19330

[Daniel J Walsh]

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(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/selinux

[Dmitry Makovey]

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_ex...

?

-- 
Dmitry Makovey
Web Systems Administrator
Athabasca University
[phone]
---
Confidence is what you have before you understand the problem
    Woody Allen

When in trouble when in doubt run in circles scream and shout
     http://www.wordwizard.com/phpbb3/viewtopic.php?f=16&t=19330

[Daniel J Walsh]

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_ex...
>
>  ?
>
>
>
>  --
>  selinux mailing list
>  selinux(a)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.

[Dmitry Makovey]

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_ex...
>
>  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 :)

-- 
Dmitry Makovey
Web Systems Administrator
Athabasca University
[phone]
---
Confidence is what you have before you understand the problem
    Woody Allen

When in trouble when in doubt run in circles scream and shout
     http://www.wordwizard.com/phpbb3/viewtopic.php?f=16&t=19330