Re: RFC: earlyinit_t

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 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.

Because of the initial sid, it couldn't be optional. Regardless, I think 
it should be it's own module, just for organizational purposes.

>>> 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 
early userspace processes exist past when the policy is loaded? Or does 
it only consist of various file descriptors passed from those early init 
processes? Does the early init domain even need rules?


>>> 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.
> 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.

>>> 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.
>>
> 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 
SELinux anyway, and I'm not aware of anyone maintaining them.


-- 
Chris PeBenito