Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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).
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