Description of problem: SELinux will deny SNMP the ability to update the /var/net-snmp/snmpd.conf file when trying to create SNMPv3 users. Please note this has only been tested on a 5.4 system so far, I will test on a 5.5 system soon and report back. node=humbert type=AVC msg=audit(1278658813.124:259644): avc: denied { getattr } for pid=374 comm="snmpd" path="/var/net-snmp/snmpd.conf" dev=sda1 ino=2720615 scontext=user_u:system_r:snmpd_t:s0 tcontext=user_u:object_r:var_t:s0 tclass=file node=humbert type=AVC msg=audit(1278658813.124:259645): avc: denied { rename } for pid=374 comm="snmpd" name="snmpd.conf" dev=sda1 ino=2720615 scontext=user_u:system_r:snmpd_t:s0 tcontext=user_u:object_r:var_t:s0 tclass=file node=humbert type=AVC msg=audit(1278658813.124:259646): avc: denied { unlink } for pid=374 comm="snmpd" name="snmpd.0.conf" dev=sda1 ino=2720615 scontext=user_u:system_r:snmpd_t:s0 tcontext=user_u:object_r:var_t:s0 tclass=file Version-Release number of selected component (if applicable): net-snmp-5.3.2.2-7.el5_4.2 selinux-policy-targeted-2.4.6-255.el5_4.4 How reproducible: Steps to Reproduce: 1. Install net-snmp net-snmp-utils and net-snmp-devel 2. Make sure snmpd is stopped 3. Create the user: sudo net-snmp-config --create-snmpv3-user -ro -a PASSWORD -X AES -A SHA USERNAME 4. Start snmpd, watch the fireworks in the audit log Actual results: SELinux denial Expected results: User to be created Additional info:
Yeah I got the same result on a 5.5 system fully updated, here is the entire output of the audit log: type=AVC msg=audit(1278694554.356:28280): avc: denied { read } for pid=12186 comm="snmpd" name="snmpd.conf" dev=sda4 ino=7929877 scontext=user_u:system_r:snmpd_t:s0 tcontext=user_u:object_r:var_t:s0 tclass=file type=AVC msg=audit(1278694554.455:28281): avc: denied { read } for pid=12186 comm="snmpd" name="snmpd.conf" dev=sda4 ino=7929877 scontext=user_u:system_r:snmpd_t:s0 tcontext=user_u:object_r:var_t:s0 tclass=file type=AVC msg=audit(1278694554.456:28282): avc: denied { getattr } for pid=12186 comm="snmpd" path="/var/net-snmp/snmpd.conf" dev=sda4 ino=7929877 scontext=user_u:system_r:snmpd_t:s0 tcontext=user_u:object_r:var_t:s0 tclass=file type=AVC msg=audit(1278694554.456:28283): avc: denied { append } for pid=12186 comm="snmpd" name="snmpd.conf" dev=sda4 ino=7929877 scontext=user_u:system_r:snmpd_t:s0 tcontext=user_u:object_r:var_t:s0 tclass=file type=AVC msg=audit(1278694554.456:28284): avc: denied { append } for pid=12186 comm="snmpd" name="snmpd.conf" dev=sda4 ino=7929877 scontext=user_u:system_r:snmpd_t:s0 tcontext=user_u:object_r:var_t:s0 tclass=file type=AVC msg=audit(1278694554.456:28285): avc: denied { append } for pid=12186 comm="snmpd" name="snmpd.conf" dev=sda4 ino=7929877 scontext=user_u:system_r:snmpd_t:s0 tcontext=user_u:object_r:var_t:s0 tclass=file type=AVC msg=audit(1278694554.457:28286): avc: denied { append } for pid=12186 comm="snmpd" name="snmpd.conf" dev=sda4 ino=7929877 scontext=user_u:system_r:snmpd_t:s0 tcontext=user_u:object_r:var_t:s0 tclass=file type=AVC msg=audit(1278694554.457:28287): avc: denied { append } for pid=12186 comm="snmpd" name="snmpd.conf" dev=sda4 ino=7929877 scontext=user_u:system_r:snmpd_t:s0 tcontext=user_u:object_r:var_t:s0 tclass=file type=AVC msg=audit(1278694554.457:28288): avc: denied { append } for pid=12186 comm="snmpd" name="snmpd.conf" dev=sda4 ino=7929877 scontext=user_u:system_r:snmpd_t:s0 tcontext=user_u:object_r:var_t:s0 tclass=file type=AVC msg=audit(1278694554.457:28289): avc: denied { append } for pid=12186 comm="snmpd" name="snmpd.conf" dev=sda4 ino=7929877 scontext=user_u:system_r:snmpd_t:s0 tcontext=user_u:object_r:var_t:s0 tclass=file type=AVC msg=audit(1278694554.457:28290): avc: denied { append } for pid=12186 comm="snmpd" name="snmpd.conf" dev=sda4 ino=7929877 scontext=user_u:system_r:snmpd_t:s0 tcontext=user_u:object_r:var_t:s0 tclass=file type=AVC msg=audit(1278694554.457:28291): avc: denied { append } for pid=12186 comm="snmpd" name="snmpd.conf" dev=sda4 ino=7929877 scontext=user_u:system_r:snmpd_t:s0 tcontext=user_u:object_r:var_t:s0 tclass=file type=AVC msg=audit(1278694554.457:28292): avc: denied { append } for pid=12186 comm="snmpd" name="snmpd.conf" dev=sda4 ino=7929877 scontext=user_u:system_r:snmpd_t:s0 tcontext=user_u:object_r:var_t:s0 tclass=file type=AVC msg=audit(1278694554.457:28293): avc: denied { append } for pid=12186 comm="snmpd" name="snmpd.conf" dev=sda4 ino=7929877 scontext=user_u:system_r:snmpd_t:s0 tcontext=user_u:object_r:var_t:s0 tclass=file type=AVC msg=audit(1278694554.457:28294): avc: denied { append } for pid=12186 comm="snmpd" name="snmpd.conf" dev=sda4 ino=7929877 scontext=user_u:system_r:snmpd_t:s0 tcontext=user_u:object_r:var_t:s0 tclass=file type=AVC msg=audit(1278694554.457:28295): avc: denied { append } for pid=12186 comm="snmpd" name="snmpd.conf" dev=sda4 ino=7929877 scontext=user_u:system_r:snmpd_t:s0 tcontext=user_u:object_r:var_t:s0 tclass=file type=AVC msg=audit(1278694554.457:28296): avc: denied { append } for pid=12186 comm="snmpd" name="snmpd.conf" dev=sda4 ino=7929877 scontext=user_u:system_r:snmpd_t:s0 tcontext=user_u:object_r:var_t:s0 tclass=file type=AVC msg=audit(1278694554.458:28297): avc: denied { append } for pid=12186 comm="snmpd" name="snmpd.conf" dev=sda4 ino=7929877 scontext=user_u:system_r:snmpd_t:s0 tcontext=user_u:object_r:var_t:s0 tclass=file type=AVC msg=audit(1278694554.458:28298): avc: denied { append } for pid=12186 comm="snmpd" name="snmpd.conf" dev=sda4 ino=7929877 scontext=user_u:system_r:snmpd_t:s0 tcontext=user_u:object_r:var_t:s0 tclass=file type=AVC msg=audit(1278694554.458:28299): avc: denied { append } for pid=12186 comm="snmpd" name="snmpd.conf" dev=sda4 ino=7929877 scontext=user_u:system_r:snmpd_t:s0 tcontext=user_u:object_r:var_t:s0 tclass=file type=AVC msg=audit(1278694554.458:28300): avc: denied { getattr } for pid=12186 comm="snmpd" path="/var/net-snmp/snmpd.conf" dev=sda4 ino=7929877 scontext=user_u:system_r:snmpd_t:s0 tcontext=user_u:object_r:var_t:s0 tclass=file
Created service request: 2038956
restorecon -R -v /var/net-snmp Should fix the label. This is not a bug.
That is interesting, yes now I see the /etc/selinux/targeted/contexts/files/file_contexts where I think these labels are derived, will check that in the future to see if this is a mislabling problem. However, when I run restorecon -R -v /var/net-snmp nothing changes on some of my systems, not all of them just some. I know this isn't really salient to this bug but do you know what might cause that issue? Thanks, -Erinn
THe systems where nothing changes are labeled correctly. If you destroy the directory and just create it by hand, it will be labeled incorrectly. You can use restorecon to fix the label. If the directory was created by rpm, it would have been labeled correctly.
If you see the label get mislabeled again please reopen the bug.
Well that is sort of the problem then, I guess restorecon does not appear to be taking this directory back to the right condition. So: erinn@barbarella /var $ sestatus SELinux status: enabled SELinuxfs mount: /selinux Current mode: enforcing Mode from config file: enforcing Policy version: 21 Policy from config file: targeted This is the incorrect label it should be system_u:object_r:snmpd_var_lib_t:s0: erinn@barbarella /var $ ls -lZd /var/net-snmp/ drwx------ root root user_u:object_r:var_t:s0 /var/net-snmp/ erinn@barbarella /var $ sudo restorecon -R -v /var/net-snmp/ erinn@barbarella /var $ ls -lZd /var/net-snmp/ drwx------ root root user_u:object_r:var_t:s0 /var/net-snmp/ It appears after further testing this out that restorecon is not working on any of my systems, and the one system that had a proper label, from the install, will not get relabled to the right label with restorecon: erinn@cc /var $ ls -lZd net-snmp/ drwx------ root root user_u:object_r:snmpd_var_lib_t net-snmp/ erinn@cc /var $ sudo mv net-snmp/ net-snmp.bak erinn@cc /var $ sudo mkdir net-snmp erinn@cc /var $ ls -lZd net-snmp drwx------ root root user_u:object_r:var_t net-snmp erinn@cc /var $ sudo restorecon -R -v /var/net-snmp erinn@cc /var $ ls -lZd /var/net-snmp drwx------ root root user_u:object_r:var_t /var/net-snmp I certainly hope I am not missing something really obvious in here.
Nope. That is correct and it is broken. rpm -q selinux-policy
I am guessing the last line there is a request for info: selinux-policy-2.4.6-279.el5 All my systems are at that same version except one 5.4 box. -Erinn
And what does matchpathcon /var/net-snmp say?
If it does not say snmpd_var_lib_t could you try yum reinstall selinux-policy-targeted and tell me if you see an error.
Here you go: erinn@cc ~ $ matchpathcon /var/net-snmp /var/net-snmp system_u:object_r:var_t erinn@cc ~ $ sudo yum reinstall selinux-policy-targeted Loaded plugins: dellsysid, rhnplugin, security Setting up Reinstall Process Resolving Dependencies --> Running transaction check ---> Package selinux-policy-targeted.noarch 0:2.4.6-279.el5 set to be updated --> Finished Dependency Resolution Dependencies Resolved ================================================================================ Package Arch Version Repository Size ================================================================================ Reinstalling: selinux-policy-targeted noarch 2.4.6-279.el5 rhel-x86_64-server-5 1.2 M Transaction Summary ================================================================================ Remove 0 Package(s) Reinstall 1 Package(s) Downgrade 0 Package(s) Total download size: 1.2 M Is this ok [y/N]: y Downloading Packages: selinux-policy-targeted-2.4.6-279.el5.noarch.rpm | 1.2 MB 00:01 Running rpm_check_debug Running Transaction Test Finished Transaction Test Transaction Test Succeeded Running Transaction Installing : selinux-policy-targeted 1/1 Installed: selinux-policy-targeted.noarch 0:2.4.6-279.el5 Complete! erinn@cc ~ $ matchpathcon /var/net-snmp /var/net-snmp system_u:object_r:var_t No error.
Interestingly one of the Red Hat support guys, Ranjith just ran restorecon on a working system and it reverted it: [test@dhcp211-205 ~]$ sudo /sbin/restorecon -R -v /var/net-snmp /sbin/restorecon reset /var/net-snmp context root:object_r:snmpd_var_lib_t:s0->system_u:object_r:var_t:s0 But this looks right from the file_contexts: /var/net-snmp(/.*) system_u:object_r:snmpd_var_lib_t:s0 Anyway, perhaps a bit more information for you. -Erinn
Miroslav, there is a bug in the regular expression. should be /var/net-snmp(/.*)? gen_context(system_u:object_r:snmpd_var_lib_t,s0) You can add this label by executing # semanage fcontext -a -t snmpd_var_lib_t '/var/net-snmp(/.*)?'
It is also broken in Fedora and RHEL6.
Dan, Thanks for the help. Glad we could get this figured out. -Erinn
Fixed in selinux-policy-2.4.6-281.el5.noarch
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: When SELinux was running in the enforcing mode, the snmpd daemon was incorrectly denied access to the /var/net-snmp/snmpd.conf configuration file. With this update, the SELinux context for the /var/net-snmp/ directory has been corrected.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2011-0026.html