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?
-- Thanks, LF
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?
-- Thanks, LF _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Because almost no apache servers would normally be walking through /etc reading configuration files. Do you scripts actually need to read these config files?
Am 09.09.2018 um 14:49 schrieb Daniel Walsh dwalsh@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.
-- LF
On 09/09/2018 09:43 AM, Leon Fauster via CentOS wrote:
Am 09.09.2018 um 14:49 schrieb Daniel Walsh dwalsh@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.
-- LF
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
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. If you feel that these files should not be part of the base_ro_files then we should open that for discussion.
On 09/09/2018 07:19 AM, Daniel Walsh wrote:
sesearch -A -s httpd_t -t system_conf_t -p read
If you feel that these files should not be part of the base_ro_files then we should open that for discussion.
I think the question was how users would know that the policy allowed access, as he was printing rules affecting httpd_t's file read access, and looking for system_conf_t in the output. I'm not sure if base_ro_files is an alias, or if there's another type of association between those two names, but I've also found that confusing in the past.
I don't see sesearch mentioned in the SELinux FAQ hosted by Fedora, and the mention in CentOS's FAQ appears to be the invocation that Leon used, which was less than helpful. I think both would be improved if they started from an AVC log entry (which does appear in Fedora's FAQ), and walked through the very simple steps of getting the type from a running process, the type from a file or other resource, and then using sesearch to find out what rules connect those two things, whether allowed or disallowed.
On 9/9/18 9:23 AM, Gordon Messmer wrote:
I don't see sesearch mentioned in the SELinux FAQ hosted by Fedora, and the mention in CentOS's FAQ appears to be the invocation that Leon used, which was less than helpful. I think both would be improved if they started from an AVC log entry (which does appear in Fedora's FAQ), and walked through the very simple steps of getting the type from a running process, the type from a file or other resource, and then using sesearch to find out what rules connect those two things, whether allowed or disallowed.
Dan, if you happen to see this, could you comment on the following with any clarifications? This is the best of my understanding, which isn't very good.
To determine what types of access are allowed by policy, first determine the context in which the process is running. Use the "Z" flag to the "ps" command to get context info for processes. In the following example, the httpd process is running in the httpd_t context.
# ps axZ | grep httpd system_u:system_r:httpd_t:s0 16821 ? S 0:00 /usr/sbin/httpd -DFOREGROUND
Next, get the context of the resource you'd like to examine. The "seinfo" command can tell you the context applied to IP ports. The "ps" command with the "Z" argument can tell you the context of processes (which might tell you whether a signal can be sent). The "ls" command with the "-Z" argument can tell you the context for files.
# seinfo --portcon=443 --protocol=tcp portcon tcp 443 system_u:object_r:http_port_t:s0 portcon tcp 1-511 system_u:object_r:reserved_port_t:s0 # ps axZ | grep /spamd system_u:system_r:spamd_t:s0 12993 ? Ss 0:06 /usr/bin/spamd --pidfile /var/run/spamd.pid -d -m5 -H -u daemon # ls -lZ /etc/passwd -rw-r--r--. root root system_u:object_r:passwd_file_t:s0 /etc/passwd
Finally, use "sesearch" to print the list of rules that allow access from the source process to the target resource. If access is not allowed, then it will be denied.
# sesearch -A -s httpd_t -t http_port_t Found 11 semantic av rules: allow httpd_t http_port_t : tcp_socket name_bind ; allow httpd_t http_port_t : udp_socket name_bind ; allow httpd_t port_type : tcp_socket { recv_msg send_msg } ; allow httpd_t port_type : udp_socket { recv_msg send_msg } ; allow httpd_t http_port_t : tcp_socket name_connect ; allow httpd_t http_port_t : tcp_socket name_connect ; allow nsswitch_domain port_type : udp_socket recv_msg ; allow nsswitch_domain port_type : udp_socket send_msg ; allow httpd_t port_type : tcp_socket name_connect ; allow nsswitch_domain reserved_port_type : tcp_socket name_connect ; allow nsswitch_domain port_type : tcp_socket { recv_msg send_msg } ;
# sesearch -A -s httpd_t -t spamd_t Found 4 semantic av rules: allow domain domain : key { search link } ; allow domain domain : fd use ; allow httpd_t domain : process getpgid ; allow daemon daemon : unix_stream_socket connectto ;
# sesearch -A -s httpd_t -t passwd_file_t Found 3 semantic av rules: allow nsswitch_domain passwd_file_t : file { ioctl read getattr lock open } ; allow httpd_t file_type : filesystem getattr ; allow httpd_t file_type : dir { getattr search open } ;
In the case that you would like to change the context of a resource so that it is allowed by the existing policy, rather than adding a new policy module, start with the AVC from /var/log/audit/audit.log:
type=AVC msg=audit(1537676446.333:11424): avc: denied { write } for pid=12997 comm=7370616D64206368696C64 name="razor" dev="dm-0" ino=133311 scontext=system_u:system_r:spamd_t:s0 tcontext=unconfined_u:object_r:spamd_etc_t:s0 tclass=dir
In this example, the spamd_t source context (scontext) is not allowed to write to a target class, directory, (tclass) in the spamd_etc_t context. You can print a list of the contexts for directories that spamd_t is allowed to write to:
# sesearch -A -s spamd_t -p write -c dir
If it is more appropriate for that directory to have another context, you can set that with semanage:
# semanage fcontext -at spamd_log_t /path/
Am 09.09.2018 um 16:19 schrieb Daniel Walsh dwalsh@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@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
On 09/10/2018 09:41 AM, Leon Fauster via CentOS wrote:
Am 09.09.2018 um 16:19 schrieb Daniel Walsh dwalsh@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@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