[refpolicy] init_upstart and the init_t->sysadm_t transition

Christopher J. PeBenito cpebenito at tresys.com
Wed Feb 24 08:27:19 CST 2010

On Tue, 2010-02-23 at 13:42 -0500, Stephen Smalley wrote:
> The refpolicy (and the example policy before it) has always defined a
> domain transition from init_t to sysadm_t on shell_exec_t in order to
> automatically transition to sysadm_t for single-user mode.  When
> distributions moved to upstart, this has to be made conditional on
> init_upstart == false since upstart runs scripts via shell commands,
> with a transition to initrc_t defined in the case where init_upstart ==
> true.  In OpenSUSE, we have now seen a case where we have a
> sysvinit-based system that also seems to be running the scripts via
> shell commands.  Although the precise reason is still unclear to me, in
> looking at the sysvinit code, I have found that this is a possible code
> path for sysvinit - it will invoke the command string via $SHELL -c if
> the command string in /etc/inittab has any meta characters or if the
> initial attempt to exec the command fails with ENOEXEC (e.g. script that
> lacks #! header).
> This suggests that the automatic transition to sysadm_t isn't reliable
> even with sysvinit and perhaps we should have just always used an
> explicit mechanism (sulogin or one could set up a script wrapper for
> establishing single-user mode with suitable transitions defined).
> Fedora is trying to resolve how to get single-user mode into an
> appropriate context, although I haven't seen a final resolution yet:
> http://lists.fedoraproject.org/pipermail/devel/2010-January/129566.html
> (original proposal was to use sulogin by default, but there was some
> opposition to that)
> I'm wondering whether we should just drop sysadm_shell_domtrans(init_t)
> altogether.  Or if we retain it, reverse the default case (and ideally
> rename the boolean to reflect the fact that it isn't dependent on use of
> upstart, although that may be difficult to do cleanly/compatibly).

There isn't a clear solution to me, since things are in flux.  Perhaps
we should just put the single user mode handling as distro build

Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150

More information about the refpolicy mailing list