[CentOS] Type enforcement / mechanism not clear

Mon Sep 10 13:41:23 UTC 2018
Leon Fauster <leonfauster at googlemail.com>

Am 09.09.2018 um 16:19 schrieb Daniel Walsh <dwalsh at redhat.com>:
> On 09/09/2018 09:43 AM, Leon Fauster via CentOS wrote:
>> Am 09.09.2018 um 14:49 schrieb Daniel Walsh <dwalsh at redhat.com>:
>>> On 09/08/2018 09:50 PM, Leon Fauster via CentOS wrote:
>>>> Any SElinux expert here - briefly:
>>>> # getenforce
>>>> Enforcing
>>>> # sesearch -ACR -s httpd_t  -c file -p read |grep system_conf_t
>>>> <no output>
>>>> # sesearch -ACR -s httpd_t  -c file -p read |grep syslog_conf_t
>>>> <no output>
>>>> # ls -laZ /etc/sysctl.conf /etc/rsyslog.conf
>>>> -rw-r--r--. root root system_u:object_r:syslog_conf_t:s0 /etc/rsyslog.conf
>>>> -rw-r--r--. root root system_u:object_r:system_conf_t:s0 /etc/sysctl.conf
>>>> # ausearch -m avc --start recent
>>>> type=SYSCALL msg=audit(1536457230.922:85): arch=c000003e syscall=6 success=no exit=-13 a0=7fff6460dcf0 a1=7fff6460dbe0 a2=7fff6460dbe0 a3=11 items=0 ppid=1362 pid=1364 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=4294967295 comm="php-fpm" exe="/usr/sbin/php-fpm" subj=system_u:system_r:httpd_t:s0 key=(null)
>>>> type=AVC msg=audit(1536457230.922:85): avc:  denied  { getattr } for  pid=1364 comm="php-fpm" path="/etc/rsyslog.conf" dev=dm-0 ino=138287 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:syslog_conf_t:s0 tclass=file
>>>> My test PHP script can read /etc/sysctl.conf but not /etc/rsyslog.conf. For both
>>>> no rule are found (sesearch above). So, why the script can read sysctl.conf?
>>> Because almost no apache servers would normally be walking through /etc reading
>>> configuration files.  Do you scripts actually need to read these config files?
>> Normally, sure - but a malicious developer (or attacker) will do. So, I'm evaluating different
>> approaches to secure our platform. Its possible to limit fs access in PHP but this comes with
>> a massive performance penalty.
>> Well, I do not want to discuss that all "etc_t" files can be read but why
>> sysctl.conf with "system_conf_t" type can be read where it shouldn't??
>> Any pointer would be greatly appreciated.
> We allow apache and all domains to read all of what we define as base_ro_file_type types.
> sesearch -A -s httpd_t -t system_conf_t -p read
> allow domain base_ro_file_type:dir { getattr ioctl lock open read search };
> allow domain base_ro_file_type:file { getattr ioctl lock open read };
> allow domain base_ro_file_type:lnk_file { getattr read };
> allow httpd_t base_ro_file_type:file { execute execute_no_trans getattr ioctl lock map open read };
> The base_ro_file_types are files executables that we consider part of the OS.  So reading them should not reveal secrets.  

Thanks for the pointer. Puuh, this gets very layered but the big picture on the other side gets more clear

So, to get a list of files that are allowed to be read, the masking attributes must be resolved:

# sesearch -ACR -s httpd_t  -p read | grep -v "_t " | head -7
Found 694 semantic av rules:
   allow domain tmpfile : file { ioctl read getattr lock append } ; 
   allow domain configfile : file { ioctl read getattr lock open } ; 
   allow domain configfile : dir { ioctl read getattr lock search open } ; 
   allow domain configfile : lnk_file { read getattr } ; 
   allow domain rpm_transition_domain : fifo_file { ioctl read write getattr lock append } ; 
   allow domain base_ro_file_type : file { ioctl read getattr lock open } ; 

Looking for sysctl.conf's type :

# for m in tmpfile configfile rpm_transition_domain base_ro_file_type ; do echo ${m}:$(seinfo -a${m} -x |grep system_conf_t) ; done
configfile: system_conf_t
base_ro_file_type: system_conf_t

If the output of sesearch shows the preferred order then the "configfile" attribute allows actually the access ?? 

> If you feel that these files should not be part of the base_ro_files then we should open that for discussion.

Despite this concrete case, a good practice is the one that follows the "need to known" principle. 
I will "disable" some read access here locally and accumulate some experiences with this approach.