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