Bug 523249 - net-snmp library breaks selinux because of creating index file
Summary: net-snmp library breaks selinux because of creating index file
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: net-snmp
Version: 5.4
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Jan Safranek
QA Contact: BaseOS QE
URL:
Whiteboard:
Depends On:
Blocks:
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:
Environment:
Last Closed: 2010-03-30 08:29:23 UTC


Attachments (Terms of Use)


Links
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:
always

Steps to Reproduce:
1. install cyrus-imapd and net-snmp
2. (re)start cyrus-imapd
3.
  
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.

http://rhn.redhat.com/errata/RHBA-2010-0253.html


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