Red Hat Bugzilla – Bug 922028
SELinux prevents snmptthandler from writing into /var/spool/snmptt/ directory
Last modified: 2014-09-30 19:34:26 EDT
Description of problem: Selinux is preventing snmptthandler for making any operations within /var/spool/snmptt/ directory. type=AVC msg=audit(1363348678.674:103900): avc: denied { write } for pid=5399 comm="snmptthandler" name="snmptt" dev=dm-5 ino=3021 scontext=system_u:system_r:snmpd_t:s0 tcontext=system_u:object_r:var_spool_t:s0 tclass=dir type=AVC msg=audit(1363348678.674:103900): avc: denied { add_name } for pid=5399 comm="snmptthandler" name="#snmptt-trap-1363348678675183" scontext=system_u:system_r:snmpd_t:s0 tcontext=system_u:object_r:var_spool_t:s0 tclass=dir type=AVC msg=audit(1363348678.674:103900): avc: denied { create } for pid=5399 comm="snmptthandler" name="#snmptt-trap-1363348678675183" scontext=system_u:system_r:snmpd_t:s0 tcontext=system_u:object_r:var_spool_t:s0 tclass=file type=AVC msg=audit(1363348678.674:103900): avc: denied { write open } for pid=5399 comm="snmptthandler" name="#snmptt-trap-1363348678675183" dev=dm-5 ino=1160 scontext=system_u:system_r:snmpd_t:s0 tcontext=system_u:object_r:var_spool_t:s0 tclass=file type=SYSCALL msg=audit(1363348678.674:103900): arch=c000003e syscall=2 success=yes exit=8 a0=f41f80 a1=241 a2=1b6 a3=7fcbb984dc10 items=0 ppid=5398 pid=5399 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="snmptthandler" exe="/usr/bin/perl" subj=system_u:system_r:snmpd_t:s0 key=(null) type=AVC msg=audit(1363348678.675:103901): avc: denied { ioctl } for pid=5399 comm="snmptthandler" path="/var/spool/snmptt/#snmptt-trap-1363348678675183" dev=dm-5 ino=1160 scontext=system_u:system_r:snmpd_t:s0 tcontext=system_u:object_r:var_spool_t:s0 tclass=file type=SYSCALL msg=audit(1363348678.675:103901): arch=c000003e syscall=16 success=no exit=-25 a0=8 a1=5401 a2=7fff1890c4f0 a3=48 items=0 ppid=5398 pid=5399 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="snmptthandler" exe="/usr/bin/perl" subj=system_u:system_r:snmpd_t:s0 key=(null) type=AVC msg=audit(1363348678.675:103902): avc: denied { getattr } for pid=5399 comm="snmptthandler" path="/var/spool/snmptt/#snmptt-trap-1363348678675183" dev=dm-5 ino=1160 scontext=system_u:system_r:snmpd_t:s0 tcontext=system_u:object_r:var_spool_t:s0 tclass=file type=SYSCALL msg=audit(1363348678.675:103902): arch=c000003e syscall=5 success=yes exit=0 a0=8 a1=f1b0a0 a2=f1b0a0 a3=0 items=0 ppid=5398 pid=5399 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="snmptthandler" exe="/usr/bin/perl" subj=system_u:system_r:snmpd_t:s0 key=(null) [root@watchdog ~]# ll -Z /var/spool/ | grep snmptt drwxr-xr-x. snmptt snmptt system_u:object_r:var_spool_t:s0 snmptt #============= snmpd_t ============== #!!!! The source type 'snmpd_t' can write to a 'dir' of the following types: # snmpd_var_lib_t, snmpd_var_run_t, usr_t, var_t, var_lib_t, var_run_t, var_log_t, root_t allow snmpd_t var_spool_t:dir { write add_name }; #!!!! The source type 'snmpd_t' can write to a 'file' of the following types: # snmpd_var_lib_t, snmpd_var_run_t, snmpd_log_t, root_t allow snmpd_t var_spool_t:file { write create open ioctl getattr }; -------> no type defined for /var/spool/snmptt/ directory Version-Release number of selected component (if applicable): snmptt-1.4-0.6.beta2.el6.noarch selinux-policy-3.7.19-195.el6_4.3.noarch selinux-policy-targeted-3.7.19-195.el6_4.3.noarch How reproducible: always thanks
# semanage fcontext -a -t snmpd_var_lib_t '/var/spool/snmptt(/.*)?' # restorecon -R -v /var/spool Should fix the problem. We need to set this up as default labeling.
e22c56cf4ef815b97a767f51e407a5264db3075d fixes this in Rawhide.
Hi Daniel, thanks did you mean that using snmpd_var_lib_t type for spool /var/spool/snmptt directory is temporary solution and you will create respective type for spool directory (i.e. snmpd_spool_t type)? thank you
No, Dan added the labeling to the Fedora policy and I will back port it to the RHEL6.5.
Michal no real reason to, they both have the same security requirements.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2013-1598.html