RFC: earlyinit_t

RFC: earlyinit_t

[Rahul Sandhu]

Hi all,

I'm writing this RFC with reference to the comment that I made earlier
with reference to userspace_initial_context[1]. This is a fairly big
change, but hopefully—once some of the details are ironed out—a future
patch could be included in the next release or possibly the one after.
I would be happy to author such a patch myself after some discussion.

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.

In terms of the permissions granted via kernel_t, I personally am not
overly concerned. They are _both_, by their nature, highly privileged.

Kernel threads run in the processor's most privileged execution state,
meaning that they have raw access to all memory, disk IO, and various
other pieces of system hardware. This makes SELinux _confinement_ of
said domain somewhat useless.

Early userspace processors are most likely started before policy load
has even occured, meaning that trying to restrict the permissions given
to their domain doesn't really achieve much; the majority, if not all,
of their tasks occur before SELinux is performing any checks.

However, this makes access of other processes _to_ these targets quite
concerning. Given their privileged nature, such domains should be, in
my opinion, considered high value targets.

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

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:

1. Does earlyinit_t belong in the kernel policy module or would a new
   policy module, earlyinit, be preferable?
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.

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.

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.

[1] https://github.com/SELinuxProject/refpolicy/pull/1164#issuecomment-4727604362
[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

-- 
Rahul Sandhu

Re: RFC: earlyinit_t

[Russell Coker]

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/

Re: RFC: earlyinit_t

[Rahul Sandhu]

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

However, it is a problem now!

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

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.

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

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.

But, I still think that's somewhat besides the point as current systems
supported by refpolicy have these things occur. I'm looking at this
precisely because of various avc logs, etc which would require giving
more access to kernel_t, something which I'm really not a fan of doing
myself given the high security nature of kernel threads.

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

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

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

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

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

Re: RFC: earlyinit_t

[Christopher J. PeBenito]

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

Re: RFC: earlyinit_t

[Rahul Sandhu]

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

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

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

This also sounds good to me.

Re: RFC: earlyinit_t

[Russell Coker]

On Friday, 19 June 2026 09:30:55 AEST Rahul Sandhu wrote:
> 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.

Who does that nowadays?

https://etbe.coker.com.au/2008/07/24/se-linux-policy-loading/

I've written about my past tests with initrd policy and why I decided that was 
a bad idea.

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

Great!

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

Re: RFC: earlyinit_t

[Russell Coker]

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/