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?
I would prefer that we confined this script if possible.
Are you getting any AVC msgs?
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.
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?
(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.
Created attachment 539560 [details] AVC messages then using type nagios_admin_plugin_exec_t
Created attachment 539566 [details] AVC messages then using type nagios_system_plugin_exec_t
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?
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?
(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.
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
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
(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
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.
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.
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 :)
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
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.
(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 :)
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?
Any news?
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.
How could I setup Openmanage? I need to create an initial policy which you could test then.
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.
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
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.
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.