Re: RFC: earlyinit_t

On Thu Jun 18, 2026 at 10:04 PM BST, Christopher J. PeBenito wrote:
> On 6/18/26 1:18 PM, Rahul Sandhu wrote:
>> On Thu Jun 18, 2026 at 4:22 PM BST, Russell Coker wrote:
>>> On Friday, 19 June 2026 00:34:01 AEST Rahul Sandhu wrote:
>>>> 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 th=
at 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.
>
> Because of the initial sid, it couldn't be optional. Regardless, I think=
=20
> it should be it's own module, just for organizational purposes.
>

Sounds good to me.

>>>> 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 would be interested to see what denials you come up with. How many=20
> early userspace processes exist past when the policy is loaded? Or does=
=20
> it only consist of various file descriptors passed from those early init=
=20
> processes? Does the early init domain even need rules?
>

I think the concern is less that and moreso when policy is loaded. Off
the top of my head, an example I can think of was one system I saw from
a little while back which had the policy binary in the initramfs itself
and hence loaded it midway through initramfs' setup and the switchroot.

I will attempt to reproduce this with plymouth later in the week.

Once policy is loaded however, I'm not aware of any _processes_ that do
persist beyond the initramfs. On my system, both journald and udev end
up re-exec'd for example.

>
>>>> 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 i=
n
>>>> my opinion.
>>> Systems without the unconfined module work well currently with a few tw=
eaks.
>> 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
>
> [...]
>
> I'd like to keep unconfined out as much possible.

Okay, I'll stick to the various subsystem specific calls. Hopefully, we
shouldn't need too much.

>
>>>> 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 sid=
e
>>>> 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 anothe=
r
>>>> 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 ev=
eryone
>>> 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 think we should drop the ubuntu blocks. They don't officially support=
=20
> SELinux anyway, and I'm not aware of anyone maintaining them.

This also sounds good to me.