This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 1290565 - /usr/share/conman/exec/ipmitool.exp needs a new selinux type
/usr/share/conman/exec/ipmitool.exp needs a new selinux type
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: selinux-policy (Show other bugs)
6.8
All Linux
unspecified Severity unspecified
: rc
: ---
Assigned To: Miroslav Grepl
Milos Malik
:
Depends On:
Blocks: 1297323 1397117
  Show dependency treegraph
 
Reported: 2015-12-10 14:53 EST by Denys Vlasenko
Modified: 2016-11-21 11:24 EST (History)
8 users (show)

See Also:
Fixed In Version: selinux-policy-3.7.19-287.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1297323 1397117 (view as bug list)
Environment:
Last Closed: 2016-05-10 16:03:36 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Denys Vlasenko 2015-12-10 14:53:00 EST
There is our customer (see BZ 1206342) who runs

/usr/share/conman/exec/ipmitool.exp

from conmand. This is a script, so it can be edited by user and can
do almost anything, we can't predict its actions (can't constrain them
to a known allowed set).

As explained in comments in that file,
conmand can "talk" to custom "consoles" via an arbitrary
helper process:

     console name="zot" dev="COMMAND ARGS"

In such a case, COMMAND inherits conmand's context, conman_t,
and when COMMAND=/usr/share/conman/exec/ipmitool.exp,
this context is too restrictive.

This situation is not new: many other daemons spawn
other, admin-defined script processes. E.g. nagios:

# seinfo -t | grep nagios
   nagios_spool_t
   nagios_admin_plugin_exec_t
   nagios_mail_plugin_exec_t
   nagios_t
   httpd_nagios_script_t
   nagios_services_plugin_exec_t
   nagios_tmp_t
   nagios_system_plugin_tmp_t
   httpd_nagios_htaccess_t
   nagios_eventhandler_plugin_exec_t
   nagios_var_lib_t
   nagios_var_run_t
   nagios_mail_plugin_t
   httpd_nagios_content_t
   nagios_unconfined_plugin_exec_t  <<--- HERE
   httpd_nagios_ra_content_t
   httpd_nagios_rw_content_t
   nagios_checkdisk_plugin_exec_t
   nagios_checkdisk_plugin_t
   nagios_services_plugin_t
   nagios_eventhandler_plugin_t
   nagios_exec_t
   nagios_system_plugin_t
   httpd_nagios_script_exec_t
   nagios_etc_t
   nagios_log_t
   nagios_unconfined_plugin_t  <<--- HERE
   nagios_eventhandler_plugin_tmp_t
   nagios_system_plugin_exec_t
   nagios_initrc_exec_t
   nagios_admin_plugin_t

I propose to add a new type, say conman_unconfined_script_t,
which gives unconfined_t-ish privileges to processes labeled with it;
and a new type, say conman_unconfined_script_exec_t,
to label executables with.

Then we can either label /usr/share/conman/exec/ipmitool.exp with it,
or (if we think this opens too big a hole if we ship it in this form),
we leave file unlabeled, but add comments therein explaining admins
that they should do that themselves (i.e. we leave it up to admins
to relax security).
Comment 5 errata-xmlrpc 2016-05-10 16:03:36 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-0763.html

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