| Message ID | 20231012103210.2915871-1-adam.duskett@amarulasolutions.com |
|---|---|
| Headers | show |
| Series | SELinux: Basic config enforcing mode support. | expand |
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
Hey Thomas, sorry for the late reply! Refpolicy itself is just that, a reference policy. Quite a few gaps are missing with several packages. In fact, Fedora/RHEL have their own policy based on the refpolicy package found here: https://github.com/fedora-selinux/selinux-policy because refpolicy itself is not adequate for a complete system in enforcing mode. Also note, that the yocto selinux layer went another route and patches refpolicy instead of providing separate selinux policy files. To summarize: These are necessary because refpolicy is not complete nor suitable for a system running in enforcing mode. On Wed, Nov 8, 2023 at 1:55 PM Thomas Petazzoni via buildroot < buildroot@buildroot.org> wrote: > 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 >
On 10/11/2023 17:49, Adam Duskett wrote: > Hey Thomas, sorry for the late reply! > > Refpolicy itself is just that, a reference policy. If refpolicy only provides a reference policy, how can Buildroot do any better? We don't do any weird things with packages, so any policy that is applicable to Buildroot is applicable to everyone. > Quite a few gaps are missing > with several packages. > In fact, Fedora/RHEL have their own policy based on the refpolicy package found > here: > https://github.com/fedora-selinux/selinux-policy > <https://github.com/fedora-selinux/selinux-policy> because refpolicy itself is > not adequate for a complete > system in enforcing mode. The basic question is: if there is anything we need to change, why would such a change not be acceptable for upstream refpolicy? Also, how come our SELinux runtime tests don't fail if the upstream refpolicy doesn't work? > Also note, that the yocto selinux layer went another route and patches refpolicy > instead of providing separate > selinux policy files. That seems like a much saner approach - I'd expect the diff to be pretty small. Also, I expect that any changes that yocto needs to make, we need to do as well - which is all the more reason to upstream them! > To summarize: These are necessary because refpolicy is not complete nor suitable > for a system running in > enforcing mode. Why does upstream refpolicy provide a "reference" that is not suitable for actual use? Not I know next to nothing about SELinux, I may be missing something glaringly obvious. Please consider all of the above questions as honest questions, not as snide remarks. Regards, Arnout > > On Wed, Nov 8, 2023 at 1:55 PM Thomas Petazzoni via buildroot > <buildroot@buildroot.org <mailto:buildroot@buildroot.org>> wrote: > > Hello Adam, > > On Thu, 12 Oct 2023 12:31:57 +0200 > Adam Duskett <adam.duskett@amarulasolutions.com > <mailto: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 <https://bootlin.com> > _______________________________________________ > buildroot mailing list > buildroot@buildroot.org <mailto:buildroot@buildroot.org> > https://lists.buildroot.org/mailman/listinfo/buildroot > <https://lists.buildroot.org/mailman/listinfo/buildroot> > > > _______________________________________________ > buildroot mailing list > buildroot@buildroot.org > https://lists.buildroot.org/mailman/listinfo/buildroot
Hello Arnout:
To answer your questions:
Q) If there is anything we need to change, why would such a change not be
acceptable for upstream refpolicy?
A) I am, but one person and I don't have time to submit all the small
changes for refpolicy.
Q) How come our SELinux runtime tests don't fail if the upstream refpolicy
doesn't work?
A) Our tests are not performed in enforcing mode.
Q) That seems like a much saner approach - I'd expect the diff to be pretty
small. Also, I expect that we need to make any changes that Yocto needs to
make
as well - which is all the more reason to upstream them!
A)
https://github.com/ni/meta-selinux/tree/nilrt/master/kirkstone/recipes-security/refpolicy/refpolicy
There are currently 74 patches to refpolicy they have made. All of
them have been submitted
upstream and all of them have been deemed Inappropriate [embedded
specific.]
So not only is the diff not small, it would be enormous compared to
this patch series.
Q) Why does upstream refpolicy provide a "reference" that is not suitable
for
actual use?
A) Ask them! It's quite frustrating! Even RHEL/Fedora does not use
refpolicy, but instead, a fork they made!
Thanks!
Adam
On Fri, Nov 10, 2023 at 12:40 PM Arnout Vandecappelle <arnout@mind.be>
wrote:
>
>
> On 10/11/2023 17:49, Adam Duskett wrote:
> > Hey Thomas, sorry for the late reply!
> >
> > Refpolicy itself is just that, a reference policy.
>
> If refpolicy only provides a reference policy, how can Buildroot do any
> better? We don't do any weird things with packages, so any policy that is
> applicable to Buildroot is applicable to everyone.
>
> > Quite a few gaps are missing
> > with several packages.
> > In fact, Fedora/RHEL have their own policy based on the refpolicy
> package found
> > here:
> > https://github.com/fedora-selinux/selinux-policy
> > <https://github.com/fedora-selinux/selinux-policy> because refpolicy
> itself is
> > not adequate for a complete
> > system in enforcing mode.
>
> The basic question is: if there is anything we need to change, why would
> such
> a change not be acceptable for upstream refpolicy?
>
> Also, how come our SELinux runtime tests don't fail if the upstream
> refpolicy
> doesn't work?
>
>
> > Also note, that the yocto selinux layer went another route and patches
> refpolicy
> > instead of providing separate
> > selinux policy files.
>
> That seems like a much saner approach - I'd expect the diff to be pretty
> small. Also, I expect that any changes that yocto needs to make, we need
> to do
> as well - which is all the more reason to upstream them!
>
>
> > To summarize: These are necessary because refpolicy is not complete nor
> suitable
> > for a system running in
> > enforcing mode.
>
> Why does upstream refpolicy provide a "reference" that is not suitable
> for
> actual use?
>
>
> Not I know next to nothing about SELinux, I may be missing something
> glaringly
> obvious. Please consider all of the above questions as honest questions,
> not as
> snide remarks.
>
> Regards,
> Arnout
>
> >
> > On Wed, Nov 8, 2023 at 1:55 PM Thomas Petazzoni via buildroot
> > <buildroot@buildroot.org <mailto:buildroot@buildroot.org>> wrote:
> >
> > Hello Adam,
> >
> > On Thu, 12 Oct 2023 12:31:57 +0200
> > Adam Duskett <adam.duskett@amarulasolutions.com
> > <mailto: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 <https://bootlin.com>
> > _______________________________________________
> > buildroot mailing list
> > buildroot@buildroot.org <mailto:buildroot@buildroot.org>
> > https://lists.buildroot.org/mailman/listinfo/buildroot
> > <https://lists.buildroot.org/mailman/listinfo/buildroot>
> >
> >
> > _______________________________________________
> > buildroot mailing list
> > buildroot@buildroot.org
> > https://lists.buildroot.org/mailman/listinfo/buildroot
>
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! Note: This series depends on the following pending patches: https://patchwork.ozlabs.org/project/buildroot/patch/20231009161817.2832969-1-adam.duskett@amarulasolutions.com/ https://patchwork.ozlabs.org/project/buildroot/patch/20231009143440.1776155-1-adam.duskett@amarulasolutions.com/ https://patchwork.ozlabs.org/project/buildroot/patch/20231009170428.2836853-1-adam.duskett@amarulasolutions.com/ Thank you for considering and reviewing this series! Adam Adam Duskett (12): package/refpolicy/selinux: Add buildroot base policy package/busybox/selinux: Add buildroot busybox policy package/sysvinit/selinux: Add buildroot sysvinit policy package/systemd/selinux: Add buildroot systemd selinux policy package/openssh/selinux: Add buildroot openssh policy package/audit/selinux: Add buildroot audit policy package/polkit/selinux: Add buildroot polkit policy package/restorecond/selinux: Add buildroot restorecond policy package/acpid/selinux: Add buildroot acpid policy package/network-manager/selinux: Add buildroot network-manager policy package/iptables/selinux: Add buildroot iptables policy package/kmod/selinux: Add buildroot kmod policy DEVELOPERS | 12 ++++ package/acpid/selinux/buildroot-acpid.fc | 0 package/acpid/selinux/buildroot-acpid.if | 1 + package/acpid/selinux/buildroot-acpid.te | 10 +++ package/audit/selinux/buildroot-audit.fc | 0 package/audit/selinux/buildroot-audit.if | 1 + package/audit/selinux/buildroot-audit.te | 13 ++++ package/busybox/selinux/buildroot-busybox.fc | 1 + package/busybox/selinux/buildroot-busybox.if | 1 + package/busybox/selinux/buildroot-busybox.te | 16 +++++ .../iptables/selinux/buildroot-iptables.fc | 0 .../iptables/selinux/buildroot-iptables.if | 1 + .../iptables/selinux/buildroot-iptables.te | 5 ++ package/kmod/selinux/buildroot-kmod.fc | 0 package/kmod/selinux/buildroot-kmod.if | 1 + package/kmod/selinux/buildroot-kmod.te | 4 ++ .../selinux/buildroot-network-manager.fc | 0 .../selinux/buildroot-network-manager.if | 1 + .../selinux/buildroot-network-manager.te | 4 ++ package/openssh/selinux/buildroot-openssh.fc | 0 package/openssh/selinux/buildroot-openssh.if | 1 + package/openssh/selinux/buildroot-openssh.te | 23 +++++++ package/polkit/selinux/buildroot-polkit.fc | 0 package/polkit/selinux/buildroot-polkit.if | 1 + package/polkit/selinux/buildroot-polkit.te | 5 ++ package/refpolicy/selinux/buildroot.fc | 0 package/refpolicy/selinux/buildroot.if | 1 + package/refpolicy/selinux/buildroot.te | 67 +++++++++++++++++++ .../selinux/buildroot-restorecond.fc | 0 .../selinux/buildroot-restorecond.if | 1 + .../selinux/buildroot-restorecond.te | 13 ++++ package/systemd/selinux/buildroot-systemd.fc | 0 package/systemd/selinux/buildroot-systemd.if | 1 + package/systemd/selinux/buildroot-systemd.te | 66 ++++++++++++++++++ .../sysvinit/selinux/buildroot-sysvinit.fc | 0 .../sysvinit/selinux/buildroot-sysvinit.if | 1 + .../sysvinit/selinux/buildroot-sysvinit.te | 8 +++ 37 files changed, 259 insertions(+) create mode 100644 package/acpid/selinux/buildroot-acpid.fc create mode 100644 package/acpid/selinux/buildroot-acpid.if create mode 100644 package/acpid/selinux/buildroot-acpid.te create mode 100644 package/audit/selinux/buildroot-audit.fc create mode 100644 package/audit/selinux/buildroot-audit.if create mode 100644 package/audit/selinux/buildroot-audit.te create mode 100644 package/busybox/selinux/buildroot-busybox.fc create mode 100644 package/busybox/selinux/buildroot-busybox.if create mode 100644 package/busybox/selinux/buildroot-busybox.te create mode 100644 package/iptables/selinux/buildroot-iptables.fc create mode 100644 package/iptables/selinux/buildroot-iptables.if create mode 100644 package/iptables/selinux/buildroot-iptables.te create mode 100644 package/kmod/selinux/buildroot-kmod.fc create mode 100644 package/kmod/selinux/buildroot-kmod.if create mode 100644 package/kmod/selinux/buildroot-kmod.te create mode 100644 package/network-manager/selinux/buildroot-network-manager.fc create mode 100644 package/network-manager/selinux/buildroot-network-manager.if create mode 100644 package/network-manager/selinux/buildroot-network-manager.te create mode 100644 package/openssh/selinux/buildroot-openssh.fc create mode 100644 package/openssh/selinux/buildroot-openssh.if create mode 100644 package/openssh/selinux/buildroot-openssh.te create mode 100644 package/polkit/selinux/buildroot-polkit.fc create mode 100644 package/polkit/selinux/buildroot-polkit.if create mode 100644 package/polkit/selinux/buildroot-polkit.te create mode 100644 package/refpolicy/selinux/buildroot.fc create mode 100644 package/refpolicy/selinux/buildroot.if create mode 100644 package/refpolicy/selinux/buildroot.te create mode 100644 package/restorecond/selinux/buildroot-restorecond.fc create mode 100644 package/restorecond/selinux/buildroot-restorecond.if create mode 100644 package/restorecond/selinux/buildroot-restorecond.te create mode 100644 package/systemd/selinux/buildroot-systemd.fc create mode 100644 package/systemd/selinux/buildroot-systemd.if create mode 100644 package/systemd/selinux/buildroot-systemd.te create mode 100644 package/sysvinit/selinux/buildroot-sysvinit.fc create mode 100644 package/sysvinit/selinux/buildroot-sysvinit.if create mode 100644 package/sysvinit/selinux/buildroot-sysvinit.te