Type Enforcement / Mechanism Not Clear

Home » CentOS » Type Enforcement / Mechanism Not Clear
CentOS 7 Comments

Any SElinux expert here – briefly:

# getenforce Enforcing

# sesearch -ACR -s httpd_t -c file -p read |grep system_conf_t

# sesearch -ACR -s httpd_t -c file -p read |grep syslog_conf_t

# 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

7 thoughts on - Type Enforcement / Mechanism Not Clear

  • 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 :

    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.  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.

  • Am 09.09.2018 um 16:19 schrieb Daniel Walsh :

    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 ??

    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.

  • 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/