Re: RFC: earlyinit_t

On 6/19/26 3:29 AM, Russell Coker wrote:
> 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.
>
Are there further arguments for doing earlyinit_t? I'm inclined to go 
with this instead: https://github.com/SELinuxProject/refpolicy/pull/1168 
but the discussion is split between that PR and here.


-- 
Chris PeBenito