Re: [Buildroot] [PATCH 00/12] SELinux: Basic config enforcing mode support.

From: Thomas Petazzoni via buildroot <buildroot@buildroot.org>
To: Adam Duskett <adam.duskett@amarulasolutions.com>
Cc: Marek Belisko <marek.belisko@open-nandra.com>,
	Antoine Tenart <atenart@kernel.org>,
	Sen Hastings <sen@phobosdpl.com>,
	Maxime Chevallier <maxime.chevallier@bootlin.com>,
	buildroot@buildroot.org, Norbert Lange <nolange79@gmail.com>,
	"Yann E . MORIN" <yann.morin.1998@free.fr>
Subject: Re: [Buildroot] [PATCH 00/12] SELinux: Basic config enforcing mode support.
Date: Wed, 8 Nov 2023 21:55:36 +0100	[thread overview]
Message-ID: <20231108215536.7a780fe2@windsurf> (raw)
In-Reply-To: <20231012103210.2915871-1-adam.duskett@amarulasolutions.com>

Hello Adam,

On Thu, 12 Oct 2023 12:31:57 +0200
Adam Duskett <adam.duskett@amarulasolutions.com> wrote:

> SELinux support in Buildroot is currently outstanding! However, one last major
> issue remains: Enforcing mode needs to work out of the box correctly, without
> denials, at least with a minimal defconfig.
> 
> This patch series seeks to remedy this problem with a basic set of policies in
> several commonly selected packages to allow a user who wishes to use SELinux in
> enforcing mode the ability to do so without having to spend several hours
> writing the same policy that everyone who wishes to do the same thing would
> have to do.
> 
> The packages I have selected are based on the pc_x86_64_bios_defconfig with all
> of the selinux packages selected because it was the most straightforward option
> I had to create a small, bootable system in Virtual Manager with ssh support to
> quickly build out a policy that didn't generate any denials in
> /var/log/audit.log.
> 
> I want to address Yann's questions from a previous discussion on IRC:
>   Q) What will be the maintenance effort?
>   A) Minimal after this patch series. As you will see, most policies are only a
>      few lines long!
> 
>   Q) How much time will we invest when we bump a package or add a dependency?
>   A) Usually none! If a package bump/new dependency requires new permissions to
>      the SELinux policy, this is a good thing! We should step back and question
>      why a package previously accessing only files and libraries suddenly needs
>      to (e.g.), change permissions on a /dev/ device!

Thanks a lot for working on this.

However, I'd like to understand why these policy files need to be in
Buildroot. For example, you're adding some policy for OpenSSH. But
Buildroot just builds upstream OpenSSH with no change. Why do we need
some policy specifically in Buildroot for OpenSSH that cannot be in
upstream refpolicy?

Back when Antoine Ténart (which you have in Cc) was working on this,
and also my colleague Maxime Chevallier (which I have added in Cc),
their plan was to make it possible to use the upstream refpolicy for a
Buildroot system, by contributing changes to the refpolicy (and they
contributed quite a few).

Why are we not continuing on this approach?

Or is your policy a "from scratch" policy that can be used as a
complete alternative to the upstream refpolicy?

(Note: we will clearly want a runtime test case for this.)

Best regards,

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot