On 09/10/2018 09:41 AM, Leon Fauster via CentOS wrote:
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
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@centos.org
https://lists.centos.org/mailman/listinfo/centos


_______________________________________________
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Reply via email to