[Buildroot] [External] Re: [PATCH v2] package/libselinux: Add autorelabel for first boot

[Weber, Matthew L Collins]

All,

> From: Yann E. MORIN <yann.morin.1998 at free.fr>
> Sent: Friday, August 20, 2021 2:16 PM
> To: José Pekkarinen <jose.pekkarinen at unikie.com>
> Cc: buildroot at buildroot.org <buildroot at buildroot.org>; Adam Duskett <aduskett at gmail.com>; Weber, Matthew L Collins <Matthew.Weber at collins.com>
> Subject: [External] Re: [Buildroot] [PATCH v2] package/libselinux: Add autorelabel for first boot
>  
> José, All,
>
> +Matthew +Adam, our resident SELinux experts: questions for you toward
> the end...
>
> (resend as I acutally forgot to add them)
>
> On 2021-08-20 15:19 +0300, José Pekkarinen spake thusly:
> > On Fri, Aug 20, 2021 at 12:05 AM Yann E. MORIN < [1]yann.morin.1998 at free.fr> wrote:
> > > On 2021-08-19 12:29 +0300, José Pekkarinen spake thusly:
> > > > Currently buildroot ship libselinux without triggering
> > > > this option, which often shows inconsistencies between
> > > > what the refpolicy defines as a label for a file and
> > > > what the actual file has. Triggering an initial relabel
> > > > would help activating enforcing state right away without
> > > > requiring to enter it once in permissive and tweak the
> > > > labels.
> [--SNIP--]
> > > Isn't this going to fail on read-only filesystems? Relabelling suposedly
> > > requires that extended attributes be added/updated/removed, and that
> > > requires a read-write filesystem...
> > > Can't we do the re-labelling at the time we create the filesystem, i.e.
> > > in fs/common.mk?
> > > And it seems we already have that:
> [--SNIP--]
> > > So why is the labelling wrong? Can't we fix it right there rather than
> > > at runtime?
> > It's is not wrong, it was just unnoticed by my eyeballs,
>
> :-)
>
> > however, there is a case this is not covering properly and preventing
> > the userspace to run right away in enforcing mode, because at
> > this time not all files in /dev are populated, and running it in
> > permissive mode multiple complains from selinux to the serial
> > devices turn up. If you have some suggestions how we can
> > improve this case, I'm happy to bring more changes.
>
> What I understand from your explanations, above, is that we have to have
> some labels (i.e. extended attributes) set on files in /dev, or the
> policy may reference objects that are not properly labeled.

I've included a few background references on file context (Yann your assumptions on IRC were correct) [2] [3].

What you guys have described is a feature missing in the current Buildroot SELinux support.  A user would need to add their own script or call restorecon manually.  As a side note, the runtime tests only cover a permissive test case, so it would miss (PASS) that every boot "/dev" and other dynamic fs will need to be labeled.  Starting in Linux 5.13, there is a feature called "genfscon" (thank you Android) which can handle this via refpolicy filtering out  (proc/debugfs/tracefs/binder/bpf/pstroe/sysfs/cgroup/cgroup) mounts and doing the labeling dynamically without a restorecon being commanded from userspace.  However, you can see that "/dev" isn't on that list, so we need an init script.

I think the fix is this proposed .autorelabel menu option.  Plus, we need to include an old script [1] I had submitted which has been tailored for Buildroot and handles memory filesystems, initial SELinux setup, and .autorelabel.  Sorry, it is in the middle of a whole lot of other patching noise, search for "b/package/refpolicy/S00selinux".

[1] https://patchwork.ozlabs.org/project/buildroot/patch/1458128701-14841-1-git-send-email-niranjan.reddy@rockwellcollins.com/
[2] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/security-enhanced_linux/chap-security-enhanced_linux-selinux_contexts#:~:text=Processes%20and%20files%20are%20labeled,to%20make%20access%20control%20decisions.
[3] https://flylib.com/books/en/2.803.1.75/1/

Best Regards,
Matt Weber