Am 09.09.2018 um 16:19 schrieb Daniel Walsh <dwa...@redhat.com>:
>
> On 09/09/2018 09:43 AM, Leon Fauster via CentOS wrote:
>> Am 09.09.2018 um 14:49 schrieb Daniel Walsh <dwa...@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
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@centos.org
https://lists.centos.org/mailman/listinfo/centos
