There is our customer (see EngineeringBZ 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).