[CentOS] Type enforcement / mechanism not clear

[Daniel Walsh]

On 09/10/2018 09:41 AM, Leon Fauster via CentOS wrote:
> 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
You could add a -c file to the above to only look at `class files`
> 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
> tmpfile:
> configfile: system_conf_t
> rpm_transition_domain:
> 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.
>
> --
> LF
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> https://lists.centos.org/mailman/listinfo/centos