Re: RFC: earlyinit_t

[Russell Coker <russell@coker.com.au>]

On Friday, 19 June 2026 03:18:44 AEST Rahul Sandhu wrote:
> > That was never a problem in the traditional Unix design.
> 
> However, it is a problem now!

It is a problem that we are left to solve after others have created it.  I am 
not opposed to solving it, but we should be clear about where blame lies.
 
> > This is a bad idea.  The initramfs should just do whatever is needed to
> > mount real root and nothing more.
> 
> I think there are _some_ advantages (e.g., logging; I find journald to
> be quite exceptional in this area at least). And yes, I too do find the
> extent of stuff created in initramfs frustrating now. Unfortunately, we
> don't really have the ability to change this for all of desktop linux,
> being outside of the purview of refpolicy's scope, leaving it for us to
> deal with.

For this to be needed for logging we need the following conditions to hold:

1) There is useful things to log in early boot which can't be logged in other 
ways (EG through the kernel message log or storing a file in a tmpfs).

2) We don't have a "stop initramfs stuff before starting real root stuff" 
cutoff.

3) Programs which log via /dev/log can't reconnect when syslogd restarts.

1 is dubious and 2 and 3 don't hold AFAIK.

If 3 holds then we could have some mechanism similar to "telinit u" or 
"systemctl daemon-reexec" to restart it.  Which we would need anyway to allow 
correctly upgrading whatever is listening to /dev/log without a reboot.

The recent systemd functionality of listening to sockets on behalf of daemons 
allows the "systemctl daemon-reexec" functionality to be centralised.  Moving 
some of that back out to other processes seems like a backward step.

I can't imagine any scenario where such sockets need to be preserved that 
doesn't lead to the inability to restart running processes to fix security 
bugs without a reboot or "systemctl soft-reboot".  But maybe even "systemctl 
soft-reboot" will be insufficient to fix such things.

NB I'm not opposing your proposed solution to the problem that is being 
imposed on us.  But we have to keep in mind that it is a problem and will have 
wider scope than just what we are doing here, including the potential for 
security problems.


> > If people continue with the bad idea of processes running from initramfs
> > to
> > multiuser mode there is no other choice.
> 
> That's not what's occuring here. systemd holds open various resources
> for processes which die off and then later start again, or sometimes do
> not even start until later. This means that, using the example of the
> journald socket which is created and held open by systemd-init very
> early in the boot process, no logs are ever lost, regardless of whether
> or not journald is stopped to be re-exec'd.

If it's only systemd holding the resources open then "systemctl daemon-reexec" 
can solve the problem and cause a domain transition, in fact that's what 
currently happens.

> > Probably best to have a new module and make it optional for systems that
> > don't do that sort of thing.
> 
> I don't see what is served by making it optional; the sid exists either
> way, it's just kernel_t. If anything, systems which don't do this sort
> of thing stand the most to gain in terms of security improvements.

It can't be optional at link time but it can be optional at compile time.

> > Systems without the unconfined module work well currently with a few
> > tweaks.
> They do! I'm not denying that at all, and I think they work well at the
> moment because of the various "subsystem unconfined" stuff that exists,
> an example being files_manage_all_files(). The point is exactly that:
> for a fair few domain, no real meaningful confinement exists (e.g. the
> init process for systemd). I'm not saying this is a fault of policy; if

system_u:system_r:init_t:s0     etbe        2561  0.0  0.0  23380  1136 ?        
S    May13   0:00 (sd-pam)

Situations like the above are a reason for having some confinement of init_t.  
The possibility of sd-pam being exploited to use one of the recent kernel 
exploits to get UID 0 isn't a good one.

> anything quite the opposite, and I think it's wise to take the step of
> accepting some of these things as somewhat scopeless. To further expand
> on my systemd example, it basically needs to read any file in theory,
> it would also need to getattr and mount on any file for sandboxing. It
> can load SELinux policy, and has such broad, sweeping access that most
> of the rules are simply there to grant it as close to full access of
> the system as possible. Without commenting on this design from init's
> perspective, I _do_ think that the _policy_ choice of accepting init's
> scope under systemd is a good one, namely because trying to fight what
> the upstream of a piece of software expects breaks robustness of policy
> with practically zero security advancements. Even if we meticulously
> went around adding type attributes to files systemd can sandbox, or the
> dev nodes it can relabel, etc, the accesses would be pretty much just
> as broad anyway, and even if they weren't, a comprimised systemd-init
> can just simply load a new policy, or modify the boot chain, etc.

I agree that complexity makes security more difficult and that simplification 
can in many situations be helful for security.  Having 36 different domains 
for systemd stuff is excessive.  We have to make some tough decisions about 
these things and I think that 36 systemd domains was not the right decision.

> > The problem with this is demonstrated by all the ifdef(`distro_ubuntu',`
> > sections in the current policy, they have 19 domains unconfined that
> > everyone else has confined.  Removing the unconfined module is a way of
> > quickly fixing that on an Ubuntu system.
> 
> Hm, that's frustrating. Maybe we could gatekeep this behind a tunable
> or something akin to that for Ubuntu users?

I am not opposed to such a tunable, hopefully we could do it in a way that the 
Ubuntu people don't object to.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/