Re: RFC: earlyinit_t

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

On Friday, 19 June 2026 00:34:01 AEST Rahul Sandhu wrote:
> kernel_t is currently a bit overloaded in terms of scope; the domain is
> used both for kernel threads and early userspace, before the transition
> that is done (typically) by the init system.

That was never a problem in the traditional Unix design.

> Unfortunately, these targets differ in terms of the level of access
> other domains require to them. Just as an example, modern systems that
> are running systemd create a plethora of sockets and other objects in
> the initramfs, so long as systemd itself is running there, that persist
> for the system's entire boot and onwards. systemd-journald's socket is
> a good example of a socket created early, which as a result ends up as
> kernel_t. For another example, I have this recent denial from udev[2].

This is a bad idea.  The initramfs should just do whatever is needed to mount 
real root and nothing more.

> Hence, I propose creating a new domain, earlyinit_t, and changing the
> init sid to use that instead of kernel_t. A couple questions linger at
> the moment off the top of my head:

If people continue with the bad idea of processes running from initramfs to 
multiuser mode there is no other choice.

> 1. Does earlyinit_t belong in the kernel policy module or would a new
>    policy module, earlyinit, be preferable?

Probably best to have a new module and make it optional for systems that don't 
do that sort of thing.

> 2. Is there any desire to add constraints via type enforcement to what
>    earlyinit_t may do? I'm not currently seeing a usecase, so I think
>    it may be tempting to give it near limitless permission.

With the unconfined.pp module loaded the domains init_t, initrc_t, and 
kernel_t are all unconfined.  But I think we should be aiming for less 
unconfined domains not more.

> I also would think it desirable to call unconfined_domain(earlyinit_t)
> in an optional policy block as that should make the boot more robust in
> my opinion.

Systems without the unconfined module work well currently with a few tweaks.

> Is there any contention to calling files_manage_all_files(earlyinit_t),
> fs_mount_all_fs(earlyinit_t), etc for each various subsystem? On a side
> note, I think it may be useful to move unconfined_domain() to another
> module. I can understand not wanting to force unconfined_t and friends
> to exist, but I think some domains end up being _basically_ unconfined
> but not really simply because we can't call unconfined_domain() always
> on them, as it's gated behind an optional policy block. This is another
> significant change, but I think the utility to it also extends beyond
> this RFC to some other domains and modules, for example init_t running
> under systemd.

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.

> [1]
> https://github.com/SELinuxProject/refpolicy/pull/1164#issuecomment-47276043
> 62 [2] avc:  denied  { read write } for  pid=1183 comm="systemd-udevd"
> path="socket:[3032]" dev="sockfs" ino=3032
> scontext=system_u:system_r:udev_t:s0 tcontext=system_u:system_r:kernel_t:s0
> tclass=netlink_kobject_uevent_socket permissive=1


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