Bug 759049 - File context for new package nagios-plugins-openmanage
Summary: File context for new package nagios-plugins-openmanage
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 19
Hardware: Unspecified
OS: Unspecified
unspecified
low
Target Milestone: ---
Assignee: Miroslav Grepl
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-12-01 10:34 UTC by Trond H. Amundsen
Modified: 2015-02-18 13:39 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-02-18 13:39:32 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Test results with various SELinux types (5.65 KB, text/plain)
2011-12-02 09:04 UTC, Trond H. Amundsen
no flags Details
AVC messages then using type nagios_admin_plugin_exec_t (11.89 KB, text/plain)
2011-12-02 10:05 UTC, Trond H. Amundsen
no flags Details
AVC messages then using type nagios_system_plugin_exec_t (12.26 KB, text/plain)
2011-12-02 10:10 UTC, Trond H. Amundsen
no flags Details
Rudimentary policy for srvadmin (12.79 KB, text/plain)
2011-12-05 12:56 UTC, Trond H. Amundsen
no flags Details
AVC messages when using the new openmanage_lib_t label (8.00 KB, text/plain)
2011-12-06 10:08 UTC, Trond H. Amundsen
no flags Details

Description Trond H. Amundsen 2011-12-01 10:34:14 UTC
The new package "nagios-plugins-openmanage", which has recently been submitted to f15, f16, epel5 and epel6, needs a proper SELinux context. This Nagios plugin may be used in two different modes: Poll a server via SNMP (directly from Nagios) or run locally and poll using Dell's Openmanage binary 'omreport'. For the latter, it is run by NRPE and needs the SELinux type "nagios_unconfined_plugin_exec_t", so this is the common denominator.

To sum up: Please add file context type "nagios_unconfined_plugin_exec_t" to this file: "/usr/lib(64)?/nagios/plugins/check_openmanage"

One last question: Should I create a separate bz for each branch?

Comment 1 Daniel Walsh 2011-12-01 16:35:36 UTC
I would prefer that we confined this script if possible.

Comment 2 Miroslav Grepl 2011-12-01 17:10:22 UTC
Are you getting any AVC msgs?

Comment 3 Trond H. Amundsen 2011-12-02 09:04:18 UTC
Created attachment 539530 [details]
Test results with various SELinux types

I agree completely, I would very much like to confine it. Unfortunately it doesn't seem to be possible with any of the existing types for Nagios plugins:

  nagios_system_plugin_exec_t
  nagios_admin_plugin_exec_t
  nagios_services_plugin_exec_t
  nagios_checkdisk_plugin_exec_t
  nagios_mail_plugin_exec_t

The attached file contains test results with all of these types (the last two were included for the sake of completeness). The tests were performed like this:

  1. Set type and clean the audit log:
       chcon -t <type> /usr/lib64/nagios/plugins/check_openmanage
       :> /var/log/audit/audit.log

  2. Initiate execution of check_openmanage from the Nagios server using NRPE.
     The NRPE service (domain=nrpe_t) will then run check_openmanage

  3. Generate test results:
       cat /var/log/audit/audit.log | audit2allow -m test1

The testing was done on an RHEL6 server with SELinux in permissive mode.

It should be noted that when running the plugin through NRPE, it facilitates Dell's Openmanage suite directly. This software is free (as in beer) but proprietary, and is very commonly installed on Dell servers for monitoring and hardware management purposes.

Comment 4 Miroslav Grepl 2011-12-02 09:39:08 UTC
Nice study. I am interested in

allow nagios_admin_plugin_t var_lib_t:file { read write open lock };
allow nagios_admin_plugin_t var_lib_t:lnk_file read;
allow nagios_admin_plugin_t var_lib_t:sock_file write;
allow nagios_system_plugin_t initrc_t:unix_stream_socket connectto;

Is there a process running as initrc_t?

# ps -eZ |grep initrc


What is path for var_lib_t type? Could you attach AVC msgs for these rules?

Comment 5 Trond H. Amundsen 2011-12-02 10:03:30 UTC
(In reply to comment #4)
> Nice study. I am interested in
> 
> allow nagios_admin_plugin_t var_lib_t:file { read write open lock };
> allow nagios_admin_plugin_t var_lib_t:lnk_file read;
> allow nagios_admin_plugin_t var_lib_t:sock_file write;
> allow nagios_system_plugin_t initrc_t:unix_stream_socket connectto;
> 
> Is there a process running as initrc_t?

Yes, several:

  # ps -eZ |grep initrc
  system_u:system_r:initrc_t:s0    4121 ?        00:00:26 dsmcad
  unconfined_u:system_r:initrc_t:s0 6816 ?       01:21:35 dsm_sa_datamgrd
  unconfined_u:system_r:initrc_t:s0 7068 ?       00:00:16 dsm_sa_eventmgr
  unconfined_u:system_r:initrc_t:s0 7127 ?       05:14:24 dsm_sa_snmpd
  unconfined_u:system_r:initrc_t:s0 7209 ?       00:00:00 dsm_om_shrsvcd
  system_u:system_r:initrc_t:s0    8586 ?        00:00:10 rhnsd
  system_u:system_r:initrc_t:s0   25044 ?        00:15:03 collectd

The interesting ones are these:

  unconfined_u:system_r:initrc_t:s0 6816 ?       01:21:35 dsm_sa_datamgrd
  unconfined_u:system_r:initrc_t:s0 7068 ?       00:00:16 dsm_sa_eventmgr
  unconfined_u:system_r:initrc_t:s0 7127 ?       05:14:24 dsm_sa_snmpd
  unconfined_u:system_r:initrc_t:s0 7209 ?       00:00:00 dsm_om_shrsvcd

They are all Dell Openmanage processes.

> What is path for var_lib_t type?

That would be this stuff:

  # ls -Za /opt/dell/srvadmin/var/lib
  drwxr-xr-x. root root system_u:object_r:var_lib_t:s0   .
  drwxr-xr-x. root root system_u:object_r:usr_t:s0       ..
  drwxr-xr-x. root root system_u:object_r:var_lib_t:s0   openmanage
  drwxr-xr-x. root root system_u:object_r:var_lib_t:s0   srvadmin-deng
  drwxr-xr-x. root root system_u:object_r:var_lib_t:s0   srvadmin-omilcore

Dell Openmanage installs under /opt/dell/srvadmin.

> Could you attach AVC msgs for these rules?

Yep, I'll attach it in a few secs.

Comment 6 Trond H. Amundsen 2011-12-02 10:05:52 UTC
Created attachment 539560 [details]
AVC messages then using type nagios_admin_plugin_exec_t

Comment 7 Trond H. Amundsen 2011-12-02 10:10:53 UTC
Created attachment 539566 [details]
AVC messages then using type nagios_system_plugin_exec_t

Comment 8 Trond H. Amundsen 2011-12-02 10:18:40 UTC
I just had an idea. The Dell Openmanage software is not available for Fedora, only for RHEL. So running the plugin locally via NRPE is not really an option on Fedora, only on RHEL. On Fedora, SNMP would be the only option and the plugin could be easily confined. Does using different contexts on Fedora and RHEL sound interesting to you?

Comment 9 Miroslav Grepl 2011-12-02 13:34:06 UTC
Ok, the problem is these services don't have own policy. This plugin should be treated by nagios_services_plugin_t domain.

We should find the best label for these lib files until we get a new policy. 

Also we try to have the same labels for Fedora and RHEL.

Could you help me to write policy for these daemons?

Comment 10 Trond H. Amundsen 2011-12-02 14:11:05 UTC
(In reply to comment #9)
> Ok, the problem is these services don't have own policy. This plugin should be
> treated by nagios_services_plugin_t domain.

Yes, that sounds ideal to me. BTW, the plugin doesn't speak to the services directly, it uses a binary (omreport) which communicates with them.

> We should find the best label for these lib files until we get a new policy. 

Ok, if I understand this correctly you propose to set a unique label in order to separate them from the herd. In that case, just adding a simple prefix 'dell_srvadmin_' should suffice, e.g.

/opt/dell/srvadmin/bin -> dell_srvadmin_bin_t
/opt/dell/srvadmin/lib64 -> dell_srvadmin_lib_t
...etc

Or did you mean finding an *existing* label to use on the files that currently have var_lib_t etc.?

> Also we try to have the same labels for Fedora and RHEL.

Yeah, I suspected as much :)

> Could you help me to write policy for these daemons?

Confining all of Dell Openmanage would probably be a lot of work. It's a rather large and complicated piece of software with no source available. That being said, there are networked services in the mix, including a web server, which should be confined. We may need to involve Dell engineers somewhere along the way. In any case, I'll help in any way that I can.

Comment 11 Trond H. Amundsen 2011-12-02 14:43:42 UTC
FYI: There is a tiny bit of info regarding Openmanage and SELinux here:
http://support.dell.com/support/edocs/software/svradmin/6.5/en/UG/HTML/appndx.htm

Comment 12 Miroslav Grepl 2011-12-05 12:16:52 UTC
Ok, I think we could find a solution without creating a new big policy for now. 

Could you attach output of

# ls -lZ /opt/dell/srvadmin

Comment 13 Trond H. Amundsen 2011-12-05 12:42:07 UTC
(In reply to comment #12)
> Could you attach output of
> 
> # ls -lZ /opt/dell/srvadmin

Sure, here it is:

drwxr-xr-x. root root system_u:object_r:bin_t:s0       bin
drwxr-xr-x. root root system_u:object_r:usr_t:s0       etc
drwxr-xr-x. root root system_u:object_r:usr_t:s0       include
drwxr-xr-x. root root system_u:object_r:lib_t:s0       lib64
drwxr-xr-x. root root system_u:object_r:bin_t:s0       sbin
drwxr-xr-x. root root system_u:object_r:usr_t:s0       share
drwxr-xr-x. root root system_u:object_r:usr_t:s0       src
drwxr-xr-x. root root system_u:object_r:usr_t:s0       var

Comment 14 Trond H. Amundsen 2011-12-05 12:56:59 UTC
Created attachment 540849 [details]
Rudimentary policy for srvadmin

I did some testing in order to grasp the scope of the work needed to confine Dell Openmanage. I created an "empty" policy which only contained a couple of new types (dell_srvadmin_t and dell_srvadmin_exec_t) and transitions to make the daemons run with domain dell_srvadmin_t. I changed the label of the binaries to dell_srvadmin_exec_t. With SELinux in permissive mode I loaded the policy and started the daemons, then used audit2allow to create a new policy. The steps were repeated until I didn't get any more AVC messages. The resulting policy is attached.

Note that this is in no way an attempt to create a usable policy, it was just an experiment. I'm a bit puzzled by the shear amount of different labels that the dell_srvadmin_t domain needs access to (typically open, read, search and getattr). I'm guessing that the daemons do something stupid and unnecessary.

Comment 15 Miroslav Grepl 2011-12-05 20:36:01 UTC
I would leave these daemons as initrc_t for now. We have policies for complex projects as are RHCS, Cloudform, etc.

Just let's add these labels with the following policy

# cat openmanage.te
policy_module(openmanage, 1.0)

# initial policy for Dell Openmanage
type openmanage_lib_t;
files_type(openmanage_t)


--
and run

# make -f /usr/share/selinux/devel/Makefile openmanage.pp
# semodule -i openmanage.pp
# chcon -R -t etc_t /opt/dell/srvadmin/etc
# chcon -R -t openmanage_lib_t /opt/dell/srvadmin/var/lib/openmanage

Now try the nagios plugin. You should see different AVC msgs.

Comment 16 Trond H. Amundsen 2011-12-06 10:08:40 UTC
Created attachment 541292 [details]
AVC messages when using the new openmanage_lib_t label

The attached file contains the AVC messages generated while using the policy below (I had to correct what I believe was a typo):

  # cat openmanage.te 
  policy_module(openmanage, 1.0)
  
  # initial policy for Dell Openmanage
  type openmanage_lib_t;
  files_type(openmanage_lib_t)

And setting the labels you suggested in comment #15.

audit2allow translates this into the following policy:

  # grep nagios /var/log/audit/audit.log | audit2allow -m foo
  
  module foo 1.0;
  
  require {
          type shell_exec_t;
          type openmanage_lib_t;
          type initrc_t;
          type nagios_services_plugin_t;
          class sock_file write;
          class unix_stream_socket connectto;
          class sem { write read create unix_write destroy };
          class lnk_file read;
          class file { execute read lock execute_no_trans write getattr open };
  }
  
  #============= nagios_services_plugin_t ==============
  allow nagios_services_plugin_t initrc_t:unix_stream_socket connectto;
  allow nagios_services_plugin_t openmanage_lib_t:file { read write getattr open lock };
  allow nagios_services_plugin_t openmanage_lib_t:lnk_file read;
  allow nagios_services_plugin_t openmanage_lib_t:sock_file write;
  allow nagios_services_plugin_t self:sem { write read create unix_write destroy };
  allow nagios_services_plugin_t shell_exec_t:file { read execute open getattr execute_no_trans };

The semaphore class is there because the plugin execures the Openmanage binary "omreport" which in turn uses a couple of semaphores. All in all it doesn't look too bad, but I'm no expert :)

Comment 17 Trond H. Amundsen 2012-01-05 20:50:54 UTC
Hello and happy new year! I hope you've all survived the holidays. I'm not sure how to move this case forward, but at least I can sum up our options the way I see them:

1. Let the plugin run unconfined, i.e. use nagios_unconfined_plugin_t label for   the executable. I know and share your concerns, but after all the plugin is utilizing unconfined 3rd-party services.

2. Confine the plugin so it works in SNMP mode (i.e. it communicates with the monitored server only via SNMP) but not with NRPE. This is not ideal but acceptable to me. However it violates the "just works" principle. Confused users would have to read the documentation and use a local policy override for the plugin to work in NRPE mode.

3. Work to confine the Openmanage services properly so that the plugin could be confined using an existing label. As discussed in previous comments, this would be a massive undertaking and doesn't seem like a feasible option.

4. Some form of hybrid, i.e. add context for the Openmanage services and create a new Nagios plugin context (or change an existing one) for them to work together.

Personally I'm leaning towards option 1, with 2 as second. Option 4 is kind of a wildcard and I can't really say if this is a good alternative or not.

-trond

Comment 18 Miroslav Grepl 2012-01-06 09:45:04 UTC
Your local policy seems fine for now. We could write up an initial policy and make these domains as unconfined domains. Then you can just remove unconfined.pp module and confine a daemon as you want.

We want to start with writing of a tool which would help you with this.

Comment 19 Trond H. Amundsen 2012-01-09 09:51:26 UTC
(In reply to comment #18)
> Your local policy seems fine for now. We could write up an initial policy and
> make these domains as unconfined domains. Then you can just remove
> unconfined.pp module and confine a daemon as you want.

I'm sorry, but that didn't make sense to me. There is no local policy. I'm not looking at making this work locally (I know how to do that). This bz is about proper SELinux labels for a new Fedora/EPEL package. Also, there is no unconfined.pp module, perhaps you meant "openmanage.pp"?

The new package is built and ready, and Bodhi keeps nagging me. If there is anything I can do to help speed up the process then please let me know. Perhaps we can go with option 2 from comment #17 until we have a more complete policy in place?

> We want to start with writing of a tool which would help you with this.

Tools are always good :)

Comment 20 Trond H. Amundsen 2012-02-02 13:02:22 UTC
It's been almost a month since the last update. What can be done to arrive at some sort of conclusion, and what can I do to help?

Comment 21 Trond H. Amundsen 2012-03-08 16:01:14 UTC
Any news?

Comment 22 Trond H. Amundsen 2012-03-21 16:59:29 UTC
Hello again. I hate to be a nag but I would really appreciate an update. I realize that this is a special case since this plugin needs to communicate with unconfined services, and as such this bz may take some time to resolve. If there is anything I can do to speed things up please let me know.

Comment 23 Miroslav Grepl 2012-03-22 08:08:50 UTC
How could I setup Openmanage? I need to create an initial policy which you could test then.

Comment 24 Trond H. Amundsen 2012-03-22 09:03:57 UTC
The following method is the most common. Prerequisites are a mainstream Dell PowerEdge server and a supported OS, e.g. RHEL:

  # Bootstrap Dell Openmanage repository (latest)
  wget -q -O - http://linux.dell.com/repo/hardware/latest/bootstrap.cgi | bash
  
  # Install OMSA packages
  yum install srvadmin-all
  
  # Setup new path (from /etc/profile.d/srvadmin-path.sh)
  bash

  # Start services
  srvadmin-services.sh start

You'll discover that Dell Openmanage is a large suite which among other things contains a web server on port 1311 (https). The utilities 'omreport' and 'omconfig' are used to report or configure the hardware, respectively.

I would originally think that implementing a full-blown policy for Dell Openmanage was beyond the scope of this bz or for RHEL/Fedora in general, after all it is 3rd-party software and not open source. However as such it is running unconfined and any selinux confinement would be a welcome improvement :)

Just to recap some from above. The Nagios plugin in the new package nagios-plugins-openmanage can communicate with Dell Openmanage in two different ways, the choice is up to the user:

1. Via SNMP over the network. In this case, the label "nagios_services_plugin_exec_t" should suffice.

2. Directly on the monitored server, using the utility 'omreport'. In this case the plugin is communicating with unconfined services and would need to run unconfined itself, i.e. "nagios_unconfined_plugin_exec_t".

Case number 2 is obviously the difficult one.

PS. Feel free to ping me on irc (nick 'trondham' on freenode) or email me directly if you'd like to discuss this off bugzilla.

Comment 28 Fedora End Of Life 2013-04-03 19:33:23 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19

Comment 29 Fedora End Of Life 2015-01-09 21:54:36 UTC
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 30 Fedora End Of Life 2015-02-18 13:39:32 UTC
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


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