Bug 523249 - net-snmp library breaks selinux because of creating index file
Summary: net-snmp library breaks selinux because of creating index file
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: net-snmp
Version: 5.4
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: Jan Safranek
QA Contact: BaseOS QE
Depends On:
TreeView+ depends on / blocked
Reported: 2009-09-14 15:14 UTC by Michal Hlavinka
Modified: 2011-06-21 13:43 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-03-30 08:29:23 UTC

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2010:0253 normal SHIPPED_LIVE net-snmp bug fix and enhancement update 2010-03-29 12:46:44 UTC
Red Hat Bugzilla 714976 None None None Never

Internal Links: 714976

Description Michal Hlavinka 2009-09-14 15:14:11 UTC
Description of problem:
when starting cyrus-imapd, selinux complains about write to  /usr/share/snmp/mibs/.index This is cause by net-snmp library and occurs only when net-snmp is installed.

How reproducible:

Steps to Reproduce:
1. install cyrus-imapd and net-snmp
2. (re)start cyrus-imapd
Actual results:
selinux denial for write to /usr/share/snmp/mibs/.index

Expected results:
/usr should work as readonly,  so maybe this file should be installed by net-snmp package or created in different directory or ....

Comment 3 Jan Safranek 2009-10-06 08:05:53 UTC
Hi Daniel,

I though this is simple bug I can handle by myself but now it seems it's quite tricky one.

Net-SNMP stores MIB files (i.e. "some data") in /usr/share/snmp/mibs directory. Libraries from net-snmp-libs read and process these files. To speed up the processing, the libraries create .index file there to cache some data. I know, caches in /usr are bad, newer Net-SNMP stores them in /var and I can backport the functionality to RHEL5 - that's not the problem here.

The libraries survive when they cannot write the .index file in /usr (or /var), it just brings small performance penalty to library initialization. Problem is, that it generates AVC in audit log - the libraries are used by many applications, cyrus-imapd is just one of them, and their policy does not allow to touch the .index file.

The .index file is quite simple and can be generated during %post of net-snmp package. But some packages (openhpi-subagent, cman in RHEL5, Fedora has more) add files to the /usr/share/snmp/mibs and the cache needs to be regenerated when the directory changes. Also customer might want to add their MIB files there. Therefore I cannot ensure the .index file is always up to date and any application which uses net-snmp-libs may try to regenerate it.

What is the right way, how to solve this using SELinux? IMHO ignoring the AVC here is not that bad idea.

Comment 4 Jan Safranek 2009-10-06 08:07:21 UTC
Here are the AVCs we are talking about.

The libraries try to create .index file:
type=AVC msg=audit(1254808966.970:42): avc:  denied  { write } for  pid=3028 comm="cyrus-master" name="mibs" dev=hda1 ino=300640 scontext=user_u:system_r:cyrus_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=dir

The libraries try to modify .index file:
type=AVC msg=audit(1254809020.112:51): avc:  denied  { write } for  pid=3266 comm="cyrus-master" name=".index" dev=hda1 ino=300768 scontext=user_u:system_r:cyrus_t:s0 tcontext=user_u:object_r:usr_t:s0 tclass=file

Comment 5 Daniel Walsh 2009-10-06 14:19:22 UTC
The problem is the index has the wrong label on it.

matchpathcon /usr/share/snmp/mibs/.index
/usr/share/snmp/mibs/.index	system_u:object_r:snmpd_var_lib_t:s0

restorecon -R -v /usr/share/snmp/mibs/.index

If a script recreates this file then make sure the restorecon command is executed on it after it is created.

Comment 6 Jan Safranek 2009-10-07 11:08:38 UTC
Oh, there already is a policy, just the context is wrong. That's something I can handle.

Comment 10 errata-xmlrpc 2010-03-30 08:29:23 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.