Minimum kernel version for SELinux userspace

Minimum kernel version for SELinux userspace

[Stephen Smalley]

There are newer kernel APIs we could leverage to further improve the
SELinux userspace, but doing so would require setting a minimum kernel
version for new SELinux userspace releases. Not sure we've done that
previously.

In particular, I'd like to be able to use some or all of the following:
open_tree() + move_mount(): v5.2
openat2(RESOLVE_*): v5.6
mount_setattr(): v5.12

The question is what if any of these can we assume to be the minimum
kernel version going forward?
- kernel.org LTS kernels span 5.10 through 6.18 currently.
- Android common kernels track LTS kernels.
- RHEL 9 kernel was 5.14-based.
- Ubuntu 22.04 kernel was 5.15-based.
- Debian 12 kernel was 6.1-based.

I would guess we could set the minimum kernel version to v5.12 and use
all of these interfaces, at least in code not used by Android.
Thoughts?

Re: Minimum kernel version for SELinux userspace

[Stephen Smalley]

On Thu, May 21, 2026 at 3:33 PM Stephen Smalley
<stephen.smalley.work@gmail.com> wrote:
>
> There are newer kernel APIs we could leverage to further improve the
> SELinux userspace, but doing so would require setting a minimum kernel
> version for new SELinux userspace releases. Not sure we've done that
> previously.
>
> In particular, I'd like to be able to use some or all of the following:
> open_tree() + move_mount(): v5.2
> openat2(RESOLVE_*): v5.6
> mount_setattr(): v5.12
>
> The question is what if any of these can we assume to be the minimum
> kernel version going forward?
> - kernel.org LTS kernels span 5.10 through 6.18 currently.
> - Android common kernels track LTS kernels.
> - RHEL 9 kernel was 5.14-based.
> - Ubuntu 22.04 kernel was 5.15-based.
> - Debian 12 kernel was 6.1-based.
>
> I would guess we could set the minimum kernel version to v5.12 and use
> all of these interfaces, at least in code not used by Android.
> Thoughts?

As further context, I'm only looking at open_tree(), move_mount(), and
mount_setattr() for sandbox/seunshare.c and at openat2(RESOLVE_*) for
sandbox/seunshare.c, restorecond/watch.c, and
libselinux/src/selinux_restorecon.c. None of these are used today by
Android AFAIK, although selinux_restorecon() was based on
selinux_android_restorecon() and might be re-unified with it some day.

It would likely also be helpful to understand whether it is worth
further rewriting of sandbox/seunshare.c or if it is likely to be
obsoleted/replaced in the near term.

Re: Minimum kernel version for SELinux userspace

[Petr Lautrbach]

Stephen Smalley <stephen.smalley.work@gmail.com> writes:

> On Thu, May 21, 2026 at 3:33 PM Stephen Smalley
> <stephen.smalley.work@gmail.com> wrote:
>>
>> There are newer kernel APIs we could leverage to further improve the
>> SELinux userspace, but doing so would require setting a minimum kernel
>> version for new SELinux userspace releases. Not sure we've done that
>> previously.
>>
>> In particular, I'd like to be able to use some or all of the following:
>> open_tree() + move_mount(): v5.2
>> openat2(RESOLVE_*): v5.6
>> mount_setattr(): v5.12
>>
>> The question is what if any of these can we assume to be the minimum
>> kernel version going forward?
>> - kernel.org LTS kernels span 5.10 through 6.18 currently.
>> - Android common kernels track LTS kernels.
>> - RHEL 9 kernel was 5.14-based.
>> - Ubuntu 22.04 kernel was 5.15-based.
>> - Debian 12 kernel was 6.1-based.
>>
>> I would guess we could set the minimum kernel version to v5.12 and use
>> all of these interfaces, at least in code not used by Android.
>> Thoughts?
>
> As further context, I'm only looking at open_tree(), move_mount(), and
> mount_setattr() for sandbox/seunshare.c and at openat2(RESOLVE_*) for
> sandbox/seunshare.c, restorecond/watch.c, and
> libselinux/src/selinux_restorecon.c. None of these are used today by
> Android AFAIK, although selinux_restorecon() was based on
> selinux_android_restorecon() and might be re-unified with it some day.
>
> It would likely also be helpful to understand whether it is worth
> further rewriting of sandbox/seunshare.c or if it is likely to be
> obsoleted/replaced in the near term.

We don't have any specific plan other than support it in existing
version for release RHELs

For future, I'd say that using bwrap could make things much easier.
And I would not mind to move sandbox out of SELinuxProject/selinux to its
own repository like SELinuxProject/sandbox.

Petr

Re: Minimum kernel version for SELinux userspace

[Thiébaud Weksteen]

On Wed, May 27, 2026 at 1:00 AM Petr Lautrbach <plautrba@redhat.com> wrote:
>
> Stephen Smalley <stephen.smalley.work@gmail.com> writes:
>
> > On Thu, May 21, 2026 at 3:33 PM Stephen Smalley
> > <stephen.smalley.work@gmail.com> wrote:
> >>
> >> There are newer kernel APIs we could leverage to further improve the
> >> SELinux userspace, but doing so would require setting a minimum kernel
> >> version for new SELinux userspace releases. Not sure we've done that
> >> previously.
> >>
> >> In particular, I'd like to be able to use some or all of the following:
> >> open_tree() + move_mount(): v5.2
> >> openat2(RESOLVE_*): v5.6
> >> mount_setattr(): v5.12
> >>
> >> The question is what if any of these can we assume to be the minimum
> >> kernel version going forward?
> >> - kernel.org LTS kernels span 5.10 through 6.18 currently.
> >> - Android common kernels track LTS kernels.
> >> - RHEL 9 kernel was 5.14-based.
> >> - Ubuntu 22.04 kernel was 5.15-based.
> >> - Debian 12 kernel was 6.1-based.
> >>
> >> I would guess we could set the minimum kernel version to v5.12 and use
> >> all of these interfaces, at least in code not used by Android.
> >> Thoughts?
> >
> > As further context, I'm only looking at open_tree(), move_mount(), and
> > mount_setattr() for sandbox/seunshare.c and at openat2(RESOLVE_*) for
> > sandbox/seunshare.c, restorecond/watch.c, and
> > libselinux/src/selinux_restorecon.c. None of these are used today by
> > Android AFAIK, although selinux_restorecon() was based on
> > selinux_android_restorecon() and might be re-unified with it some day.

Thanks for modernizing the codebase and sharing the plan Stephen. I
don't see any issue on the Android side.

Re: Minimum kernel version for SELinux userspace

[Stephen Smalley]

On Tue, May 26, 2026 at 10:52 AM Petr Lautrbach <plautrba@redhat.com> wrote:
>
> Stephen Smalley <stephen.smalley.work@gmail.com> writes:
>
> > On Thu, May 21, 2026 at 3:33 PM Stephen Smalley
> > <stephen.smalley.work@gmail.com> wrote:
> >>
> >> There are newer kernel APIs we could leverage to further improve the
> >> SELinux userspace, but doing so would require setting a minimum kernel
> >> version for new SELinux userspace releases. Not sure we've done that
> >> previously.
> >>
> >> In particular, I'd like to be able to use some or all of the following:
> >> open_tree() + move_mount(): v5.2
> >> openat2(RESOLVE_*): v5.6
> >> mount_setattr(): v5.12
> >>
> >> The question is what if any of these can we assume to be the minimum
> >> kernel version going forward?
> >> - kernel.org LTS kernels span 5.10 through 6.18 currently.
> >> - Android common kernels track LTS kernels.
> >> - RHEL 9 kernel was 5.14-based.
> >> - Ubuntu 22.04 kernel was 5.15-based.
> >> - Debian 12 kernel was 6.1-based.
> >>
> >> I would guess we could set the minimum kernel version to v5.12 and use
> >> all of these interfaces, at least in code not used by Android.
> >> Thoughts?
> >
> > As further context, I'm only looking at open_tree(), move_mount(), and
> > mount_setattr() for sandbox/seunshare.c and at openat2(RESOLVE_*) for
> > sandbox/seunshare.c, restorecond/watch.c, and
> > libselinux/src/selinux_restorecon.c. None of these are used today by
> > Android AFAIK, although selinux_restorecon() was based on
> > selinux_android_restorecon() and might be re-unified with it some day.
> >
> > It would likely also be helpful to understand whether it is worth
> > further rewriting of sandbox/seunshare.c or if it is likely to be
> > obsoleted/replaced in the near term.
>
> We don't have any specific plan other than support it in existing
> version for release RHELs
>
> For future, I'd say that using bwrap could make things much easier.
> And I would not mind to move sandbox out of SELinuxProject/selinux to its
> own repository like SELinuxProject/sandbox.

Ok, do you have an opinion on setting a minimum kernel version for
future SELinux userspace releases (not 3.11, but say 3.12 and later)
so we can start using some or all of these interfaces without
requiring backward-compatibility fallbacks?

Re: Minimum kernel version for SELinux userspace

[Thiébaud Weksteen]

On Thu, May 28, 2026 at 5:48 AM Stephen Smalley
<stephen.smalley.work@gmail.com> wrote:
>
> On Tue, May 26, 2026 at 10:52 AM Petr Lautrbach <plautrba@redhat.com> wrote:
> >
> > Stephen Smalley <stephen.smalley.work@gmail.com> writes:
> >
> > > On Thu, May 21, 2026 at 3:33 PM Stephen Smalley
> > > <stephen.smalley.work@gmail.com> wrote:
> > >>
> > >> There are newer kernel APIs we could leverage to further improve the
> > >> SELinux userspace, but doing so would require setting a minimum kernel
> > >> version for new SELinux userspace releases. Not sure we've done that
> > >> previously.
> > >>
> > >> In particular, I'd like to be able to use some or all of the following:
> > >> open_tree() + move_mount(): v5.2
> > >> openat2(RESOLVE_*): v5.6
> > >> mount_setattr(): v5.12
> > >>
> > >> The question is what if any of these can we assume to be the minimum
> > >> kernel version going forward?
> > >> - kernel.org LTS kernels span 5.10 through 6.18 currently.
> > >> - Android common kernels track LTS kernels.
> > >> - RHEL 9 kernel was 5.14-based.
> > >> - Ubuntu 22.04 kernel was 5.15-based.
> > >> - Debian 12 kernel was 6.1-based.
> > >>
> > >> I would guess we could set the minimum kernel version to v5.12 and use
> > >> all of these interfaces, at least in code not used by Android.
> > >> Thoughts?
> > >
> > > As further context, I'm only looking at open_tree(), move_mount(), and
> > > mount_setattr() for sandbox/seunshare.c and at openat2(RESOLVE_*) for
> > > sandbox/seunshare.c, restorecond/watch.c, and
> > > libselinux/src/selinux_restorecon.c. None of these are used today by
> > > Android AFAIK, although selinux_restorecon() was based on
> > > selinux_android_restorecon() and might be re-unified with it some day.
> > >
> > > It would likely also be helpful to understand whether it is worth
> > > further rewriting of sandbox/seunshare.c or if it is likely to be
> > > obsoleted/replaced in the near term.
> >
> > We don't have any specific plan other than support it in existing
> > version for release RHELs
> >
> > For future, I'd say that using bwrap could make things much easier.
> > And I would not mind to move sandbox out of SELinuxProject/selinux to its
> > own repository like SELinuxProject/sandbox.
>
> Ok, do you have an opinion on setting a minimum kernel version for
> future SELinux userspace releases (not 3.11, but say 3.12 and later)
> so we can start using some or all of these interfaces without
> requiring backward-compatibility fallbacks?
>

The most up-to-date documentation for this discussion is the
compatibility matrix [1]. It matches the kernel versions we support to
their Android versions. Since we only pull in the latest libselinux
for the latest Android version, you can focus on the top row. As you
mentioned, this aligns with the LTS versions. Currently, Android 17
will be the last release to support 5.10. The next version will be
5.15.

To your question, it depends when you expect 3.12 to be released. 5.15
would be a safe bet right now.

[1] https://source.android.com/docs/core/architecture/kernel/android-common#compatibility-matrix

Re: Minimum kernel version for SELinux userspace

[Petr Lautrbach]

Stephen Smalley <stephen.smalley.work@gmail.com> writes:

> On Tue, May 26, 2026 at 10:52 AM Petr Lautrbach <plautrba@redhat.com> wrote:
>>
>> Stephen Smalley <stephen.smalley.work@gmail.com> writes:
>>
>> > On Thu, May 21, 2026 at 3:33 PM Stephen Smalley
>> > <stephen.smalley.work@gmail.com> wrote:
>> >>
>> >> There are newer kernel APIs we could leverage to further improve the
>> >> SELinux userspace, but doing so would require setting a minimum kernel
>> >> version for new SELinux userspace releases. Not sure we've done that
>> >> previously.
>> >>
>> >> In particular, I'd like to be able to use some or all of the following:
>> >> open_tree() + move_mount(): v5.2
>> >> openat2(RESOLVE_*): v5.6
>> >> mount_setattr(): v5.12
>> >>
>> >> The question is what if any of these can we assume to be the minimum
>> >> kernel version going forward?
>> >> - kernel.org LTS kernels span 5.10 through 6.18 currently.
>> >> - Android common kernels track LTS kernels.
>> >> - RHEL 9 kernel was 5.14-based.
>> >> - Ubuntu 22.04 kernel was 5.15-based.
>> >> - Debian 12 kernel was 6.1-based.
>> >>
>> >> I would guess we could set the minimum kernel version to v5.12 and use
>> >> all of these interfaces, at least in code not used by Android.
>> >> Thoughts?
>> >
>> > As further context, I'm only looking at open_tree(), move_mount(), and
>> > mount_setattr() for sandbox/seunshare.c and at openat2(RESOLVE_*) for
>> > sandbox/seunshare.c, restorecond/watch.c, and
>> > libselinux/src/selinux_restorecon.c. None of these are used today by
>> > Android AFAIK, although selinux_restorecon() was based on
>> > selinux_android_restorecon() and might be re-unified with it some day.
>> >
>> > It would likely also be helpful to understand whether it is worth
>> > further rewriting of sandbox/seunshare.c or if it is likely to be
>> > obsoleted/replaced in the near term.
>>
>> We don't have any specific plan other than support it in existing
>> version for release RHELs
>>
>> For future, I'd say that using bwrap could make things much easier.
>> And I would not mind to move sandbox out of SELinuxProject/selinux to its
>> own repository like SELinuxProject/sandbox.
>
> Ok, do you have an opinion on setting a minimum kernel version for
> future SELinux userspace releases (not 3.11, but say 3.12 and later)
> so we can start using some or all of these interfaces without
> requiring backward-compatibility fallbacks?

The only longterm kernel which does not support mount_setattr() seems to
be 5.10.257. And you need this only for seunshare which is not a core
component. Therefore I'd set the minimum on mount_setattr() v5.12 and
label seunshare as unsupported and let it fail on older kernels.

Petr