* [Buildroot] [PATCH v2] package/libselinux: Add autorelabel for first boot @ 2021-08-19 9:29 José Pekkarinen 2021-08-19 21:05 ` Yann E. MORIN 0 siblings, 1 reply; 9+ messages in thread From: José Pekkarinen @ 2021-08-19 9:29 UTC (permalink / raw) To: buildroot; +Cc: José Pekkarinen 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. Signed-off-by: José Pekkarinen <jose.pekkarinen@unikie.com> --- [ v1 -> v2 ] Fix if statement in libselinux recipe package/libselinux/Config.in | 7 +++++++ package/libselinux/libselinux.mk | 3 +++ 2 files changed, 10 insertions(+) diff --git a/package/libselinux/Config.in b/package/libselinux/Config.in index 62070c8d59..df8bd7ffd0 100644 --- a/package/libselinux/Config.in +++ b/package/libselinux/Config.in @@ -18,3 +18,10 @@ config BR2_PACKAGE_LIBSELINUX comment "libselinux needs a toolchain w/ threads, dynamic library" depends on !BR2_TOOLCHAIN_HAS_THREADS || BR2_STATIC_LIBS + +config BR2_PACKAGE_LIBSELINUX_AUTORELABEL + bool + depends on BR2_PACKAGE_LIBSELINUX + depends on BR2_PACKAGE_FINDUTILS + depends on BR2_PACKAGE_GREP + default y diff --git a/package/libselinux/libselinux.mk b/package/libselinux/libselinux.mk index fdd13aa942..adf4b3d6f6 100644 --- a/package/libselinux/libselinux.mk +++ b/package/libselinux/libselinux.mk @@ -71,6 +71,9 @@ define LIBSELINUX_INSTALL_TARGET_CMDS $(TARGET_MAKE_ENV) $(MAKE) -C $(@D) \ $(LIBSELINUX_MAKE_OPTS) DESTDIR=$(TARGET_DIR) \ $(LIBSELINUX_MAKE_INSTALL_TARGETS) + $(if $(BR2_PACKAGE_LIBSELINUX_AUTORELABEL), + echo "-F" > $(TARGET_DIR)/.autorelabel + mkdir $(TARGET_DIR)/var/lib/selinux) if ! grep -q "selinuxfs" $(TARGET_DIR)/etc/fstab; then \ echo "none /sys/fs/selinux selinuxfs noauto 0 0" >> $(TARGET_DIR)/etc/fstab ; fi endef -- 2.25.1 _______________________________________________ buildroot mailing list buildroot@busybox.net http://lists.busybox.net/mailman/listinfo/buildroot ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [Buildroot] [PATCH v2] package/libselinux: Add autorelabel for first boot 2021-08-19 9:29 [Buildroot] [PATCH v2] package/libselinux: Add autorelabel for first boot José Pekkarinen @ 2021-08-19 21:05 ` Yann E. MORIN 2021-08-20 12:19 ` José Pekkarinen 0 siblings, 1 reply; 9+ messages in thread From: Yann E. MORIN @ 2021-08-19 21:05 UTC (permalink / raw) To: José Pekkarinen; +Cc: buildroot José, All, 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. > > Signed-off-by: José Pekkarinen <jose.pekkarinen@unikie.com> > --- > [ v1 -> v2 ] Fix if statement in libselinux recipe > > package/libselinux/Config.in | 7 +++++++ > package/libselinux/libselinux.mk | 3 +++ > 2 files changed, 10 insertions(+) > > diff --git a/package/libselinux/Config.in b/package/libselinux/Config.in > index 62070c8d59..df8bd7ffd0 100644 > --- a/package/libselinux/Config.in > +++ b/package/libselinux/Config.in > @@ -18,3 +18,10 @@ config BR2_PACKAGE_LIBSELINUX > > comment "libselinux needs a toolchain w/ threads, dynamic library" > depends on !BR2_TOOLCHAIN_HAS_THREADS || BR2_STATIC_LIBS > + > +config BR2_PACKAGE_LIBSELINUX_AUTORELABEL > + bool > + depends on BR2_PACKAGE_LIBSELINUX > + depends on BR2_PACKAGE_FINDUTILS > + depends on BR2_PACKAGE_GREP > + default y > diff --git a/package/libselinux/libselinux.mk b/package/libselinux/libselinux.mk > index fdd13aa942..adf4b3d6f6 100644 > --- a/package/libselinux/libselinux.mk > +++ b/package/libselinux/libselinux.mk > @@ -71,6 +71,9 @@ define LIBSELINUX_INSTALL_TARGET_CMDS > $(TARGET_MAKE_ENV) $(MAKE) -C $(@D) \ > $(LIBSELINUX_MAKE_OPTS) DESTDIR=$(TARGET_DIR) \ > $(LIBSELINUX_MAKE_INSTALL_TARGETS) > + $(if $(BR2_PACKAGE_LIBSELINUX_AUTORELABEL), > + echo "-F" > $(TARGET_DIR)/.autorelabel > + mkdir $(TARGET_DIR)/var/lib/selinux) 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: 52 ifeq ($(BR2_PACKAGE_REFPOLICY),y) 53 define ROOTFS_SELINUX 54 $(HOST_DIR)/sbin/setfiles -m -r $(TARGET_DIR) \ 55 -c $(TARGET_DIR)/etc/selinux/targeted/policy/policy.$(BR2_PACKAGE_LIBSEPOL_POLICY_VERSION) \ 56 $(TARGET_DIR)/etc/selinux/targeted/contexts/files/file_contexts \ 57 $(TARGET_DIR) 58 endef 59 ROOTFS_COMMON_DEPENDENCIES += host-policycoreutils 60 endif So why is the labelling wrong? Can't we fix it right there rather than at runtime? Regards, Yann E. MORIN. > if ! grep -q "selinuxfs" $(TARGET_DIR)/etc/fstab; then \ > echo "none /sys/fs/selinux selinuxfs noauto 0 0" >> $(TARGET_DIR)/etc/fstab ; fi > endef > -- > 2.25.1 > > _______________________________________________ > buildroot mailing list > buildroot@busybox.net > http://lists.busybox.net/mailman/listinfo/buildroot -- .-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 561 099 427 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------' _______________________________________________ buildroot mailing list buildroot@busybox.net http://lists.busybox.net/mailman/listinfo/buildroot ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Buildroot] [PATCH v2] package/libselinux: Add autorelabel for first boot 2021-08-19 21:05 ` Yann E. MORIN @ 2021-08-20 12:19 ` José Pekkarinen 2021-08-20 19:15 ` Yann E. MORIN 2021-08-20 19:16 ` Yann E. MORIN 0 siblings, 2 replies; 9+ messages in thread From: José Pekkarinen @ 2021-08-20 12:19 UTC (permalink / raw) To: Yann E. MORIN; +Cc: buildroot [-- Attachment #1.1: Type: text/plain, Size: 3402 bytes --] On Fri, Aug 20, 2021 at 12:05 AM Yann E. MORIN <yann.morin.1998@free.fr> wrote: > José, All, > > 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. > > > > Signed-off-by: José Pekkarinen <jose.pekkarinen@unikie.com> > > --- > > [ v1 -> v2 ] Fix if statement in libselinux recipe > > > > package/libselinux/Config.in | 7 +++++++ > > package/libselinux/libselinux.mk | 3 +++ > > 2 files changed, 10 insertions(+) > > > > diff --git a/package/libselinux/Config.in b/package/libselinux/Config.in > > index 62070c8d59..df8bd7ffd0 100644 > > --- a/package/libselinux/Config.in > > +++ b/package/libselinux/Config.in > > @@ -18,3 +18,10 @@ config BR2_PACKAGE_LIBSELINUX > > > > comment "libselinux needs a toolchain w/ threads, dynamic library" > > depends on !BR2_TOOLCHAIN_HAS_THREADS || BR2_STATIC_LIBS > > + > > +config BR2_PACKAGE_LIBSELINUX_AUTORELABEL > > + bool > > + depends on BR2_PACKAGE_LIBSELINUX > > + depends on BR2_PACKAGE_FINDUTILS > > + depends on BR2_PACKAGE_GREP > > + default y > > diff --git a/package/libselinux/libselinux.mk b/package/libselinux/ > libselinux.mk > > index fdd13aa942..adf4b3d6f6 100644 > > --- a/package/libselinux/libselinux.mk > > +++ b/package/libselinux/libselinux.mk > > @@ -71,6 +71,9 @@ define LIBSELINUX_INSTALL_TARGET_CMDS > > $(TARGET_MAKE_ENV) $(MAKE) -C $(@D) \ > > $(LIBSELINUX_MAKE_OPTS) DESTDIR=$(TARGET_DIR) \ > > $(LIBSELINUX_MAKE_INSTALL_TARGETS) > > + $(if $(BR2_PACKAGE_LIBSELINUX_AUTORELABEL), > > + echo "-F" > $(TARGET_DIR)/.autorelabel > > + mkdir $(TARGET_DIR)/var/lib/selinux) > > 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: > > 52 ifeq ($(BR2_PACKAGE_REFPOLICY),y) > 53 define ROOTFS_SELINUX > 54 $(HOST_DIR)/sbin/setfiles -m -r $(TARGET_DIR) \ > 55 -c > $(TARGET_DIR)/etc/selinux/targeted/policy/policy.$(BR2_PACKAGE_LIBSEPOL_POLICY_VERSION) > \ > 56 > $(TARGET_DIR)/etc/selinux/targeted/contexts/files/file_contexts \ > 57 $(TARGET_DIR) > 58 endef > 59 ROOTFS_COMMON_DEPENDENCIES += host-policycoreutils > 60 endif > > 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. Best regards. José. [-- Attachment #1.2: Type: text/html, Size: 5022 bytes --] [-- Attachment #2: Type: text/plain, Size: 145 bytes --] _______________________________________________ buildroot mailing list buildroot@busybox.net http://lists.busybox.net/mailman/listinfo/buildroot ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Buildroot] [PATCH v2] package/libselinux: Add autorelabel for first boot 2021-08-20 12:19 ` José Pekkarinen @ 2021-08-20 19:15 ` Yann E. MORIN 2021-08-20 19:16 ` Yann E. MORIN 1 sibling, 0 replies; 9+ messages in thread From: Yann E. MORIN @ 2021-08-20 19:15 UTC (permalink / raw) To: José Pekkarinen; +Cc: buildroot José, All, +Matthew +Adam, our resident SELinux experts: questions for you toward the end... 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@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. OK, so this hit the thick wall circling around my very limited knowledge of how SELinux works. Matthew, Adam, any help/explanations/details/review would be much welcome. Regards, Yann E. MORIN. -- .-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 561 099 427 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------' _______________________________________________ buildroot mailing list buildroot@busybox.net http://lists.busybox.net/mailman/listinfo/buildroot ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Buildroot] [PATCH v2] package/libselinux: Add autorelabel for first boot 2021-08-20 12:19 ` José Pekkarinen 2021-08-20 19:15 ` Yann E. MORIN @ 2021-08-20 19:16 ` Yann E. MORIN 2021-08-23 5:43 ` José Pekkarinen 2021-08-23 14:19 ` [Buildroot] [External] " Weber, Matthew L Collins via buildroot 1 sibling, 2 replies; 9+ messages in thread From: Yann E. MORIN @ 2021-08-20 19:16 UTC (permalink / raw) To: José Pekkarinen; +Cc: Weber, Matthew L Collins, Adam Duskett, buildroot 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@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. OK, so this hit the thick wall circling around my very limited knowledge of how SELinux works. Matthew, Adam, any help/explanations/details/review would be much welcome. Regards, Yann E. MORIN. -- .-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 561 099 427 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------' _______________________________________________ buildroot mailing list buildroot@busybox.net http://lists.busybox.net/mailman/listinfo/buildroot ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Buildroot] [PATCH v2] package/libselinux: Add autorelabel for first boot 2021-08-20 19:16 ` Yann E. MORIN @ 2021-08-23 5:43 ` José Pekkarinen 2021-08-23 14:19 ` [Buildroot] [External] " Weber, Matthew L Collins via buildroot 1 sibling, 0 replies; 9+ messages in thread From: José Pekkarinen @ 2021-08-23 5:43 UTC (permalink / raw) To: Yann E. MORIN; +Cc: Weber, Matthew L Collins, Adam Duskett, buildroot [-- Attachment #1.1: Type: text/plain, Size: 4428 bytes --] On Fri, Aug 20, 2021 at 10:17 PM Yann E. MORIN <yann.morin.1998@free.fr> wrote: > 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@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. > You are right, since, for example, if you just activate selinux in permissive mode, you can see the following avcs in the console coming up: [ 0.936152] audit: type=1400 audit(1629697223.045:3): avc: denied { read write } for pid=81 comm="sh" path="/dev/console" dev="devtmpfs" ino=13 scontext=system_u:system_r:sysadm_t tcontext=system_u:object_r:device_t tclass=chr_file permissive=1 [ 0.940632] audit: type=1400 audit(1629697223.050:4): avc: denied { open } for pid=81 comm="sh" path="/dev/tty" dev="devtmpfs" ino=12 scontext=system_u:system_r:sysadm_t tcontext=system_u:object_r:device_t tclass=chr_file permissive=1 [ 0.942731] audit: type=1400 audit(1629697223.052:5): avc: denied { ioctl } for pid=81 comm="sh" path="/dev/console" dev="devtmpfs" ino=13 ioctlcmd=0x540f scontext=system_u:system_r:sysadm_t tcontext=system_u:object_r:device_t tclass=chr_file permissive=1 [ 0.944298] ln (81) used greatest stack depth: 13272 bytes left INIT: Entering runlevel: 3 Starting syslogd: OK [ 0.952061] audit: type=1400 audit(1629697223.061:6): avc: denied { read write } for pid=99 comm="syslogd" path="/dev/null" dev="devtmpfs" ino=5 scontext=system_u:system_r:syslogd_t tcontext=system_u:object_r:device_t tclass=chr_file permissive=1 [ 0.953337] audit: type=1400 audit(1629697223.063:7): avc: denied { read } for pid=99 comm="syslogd" name="log" dev="vda" ino=1891 scontext=system_u:system_r:syslogd_t tcontext=system_u:object_r:var_t tclass=lnk_file permissive=1 [ 0.954209] audit: type=1400 audit(1629697223.063:8): avc: denied { search } for pid=99 comm="syslogd" name="/" dev="tmpfs" ino=1 scontext=system_u:system_r:syslogd_t tcontext=system_u:object_r:tmpfs_t tclass=dir permissive=1 [ 0.955091] audit: type=1400 audit(1629697223.064:9): avc: denied { write } for pid=99 comm="syslogd" name="/" dev="tmpfs" ino=1 scontext=system_u:system_r:syslogd_t tcontext=system_u:object_r:tmpfs_t tclass=dir permissive=1 [ 0.956182] audit: type=1400 audit(1629697223.064:10): avc: denied { add_name } for pid=99 comm="syslogd" name="messages" scontext=system_u:system_r:syslogd_t tcontext=system_u:object_r:tmpfs_t tclass=dir permissive=1 I'm using the reference policy version 32. If this is executed in enforcing mode, at this time there would be no process remaining in the system. Thanks! José. [-- Attachment #1.2: Type: text/html, Size: 5789 bytes --] [-- Attachment #2: Type: text/plain, Size: 145 bytes --] _______________________________________________ buildroot mailing list buildroot@busybox.net http://lists.busybox.net/mailman/listinfo/buildroot ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Buildroot] [External] Re: [PATCH v2] package/libselinux: Add autorelabel for first boot 2021-08-20 19:16 ` Yann E. MORIN 2021-08-23 5:43 ` José Pekkarinen @ 2021-08-23 14:19 ` Weber, Matthew L Collins via buildroot 2021-08-25 11:33 ` José Pekkarinen 1 sibling, 1 reply; 9+ messages in thread From: Weber, Matthew L Collins via buildroot @ 2021-08-23 14:19 UTC (permalink / raw) To: Yann E. MORIN, José Pekkarinen; +Cc: Adam Duskett, buildroot All, > From: Yann E. MORIN <yann.morin.1998@free.fr> > Sent: Friday, August 20, 2021 2:16 PM > To: José Pekkarinen <jose.pekkarinen@unikie.com> > Cc: buildroot@buildroot.org <buildroot@buildroot.org>; Adam Duskett <aduskett@gmail.com>; Weber, Matthew L Collins <Matthew.Weber@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@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 _______________________________________________ buildroot mailing list buildroot@busybox.net http://lists.busybox.net/mailman/listinfo/buildroot ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Buildroot] [External] Re: [PATCH v2] package/libselinux: Add autorelabel for first boot 2021-08-23 14:19 ` [Buildroot] [External] " Weber, Matthew L Collins via buildroot @ 2021-08-25 11:33 ` José Pekkarinen 2021-09-03 6:53 ` José Pekkarinen 0 siblings, 1 reply; 9+ messages in thread From: José Pekkarinen @ 2021-08-25 11:33 UTC (permalink / raw) To: Weber, Matthew L Collins; +Cc: Yann E. MORIN, Adam Duskett, buildroot [-- Attachment #1.1: Type: text/plain, Size: 4646 bytes --] On Mon, Aug 23, 2021 at 5:19 PM Weber, Matthew L Collins < Matthew.Weber@collins.com> wrote: > All, > > > From: Yann E. MORIN <yann.morin.1998@free.fr> > > Sent: Friday, August 20, 2021 2:16 PM > > To: José Pekkarinen <jose.pekkarinen@unikie.com> > > Cc: buildroot@buildroot.org <buildroot@buildroot.org>; Adam Duskett < > aduskett@gmail.com>; Weber, Matthew L Collins <Matthew.Weber@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@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 Hi, I'm afraid the init script may not work since it references paths only existing in Centos, not in buildroot userspace(specifically, /usr/share/selinux/ and /selinux/enforce). However, we could use it to add the missing pieces of autorelabel for the restorecond init script or fix it and submit it. I'm happy to go for it, I'd like to hear what the upstream point of view is. Thanks! José. [-- Attachment #1.2: Type: text/html, Size: 6971 bytes --] [-- Attachment #2: Type: text/plain, Size: 145 bytes --] _______________________________________________ buildroot mailing list buildroot@busybox.net http://lists.busybox.net/mailman/listinfo/buildroot ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Buildroot] [External] Re: [PATCH v2] package/libselinux: Add autorelabel for first boot 2021-08-25 11:33 ` José Pekkarinen @ 2021-09-03 6:53 ` José Pekkarinen 0 siblings, 0 replies; 9+ messages in thread From: José Pekkarinen @ 2021-09-03 6:53 UTC (permalink / raw) To: Weber, Matthew L Collins; +Cc: Yann E. MORIN, Adam Duskett, buildroot [-- Attachment #1.1: Type: text/plain, Size: 978 bytes --] On Wed, Aug 25, 2021 at 2:33 PM José Pekkarinen <jose.pekkarinen@unikie.com> wrote: > > > On Mon, Aug 23, 2021 at 5:19 PM Weber, Matthew L Collins < > Matthew.Weber@collins.com> wrote: > >> >> > Hi, > > I'm afraid the init script may not work since it > > references paths only existing in Centos, not in buildroot > userspace(specifically, /usr/share/selinux/ and > /selinux/enforce). However, we could use it to add the > missing pieces of autorelabel for the restorecond init script > or fix it and submit it. I'm happy to go for it, I'd like to hear > what the upstream point of view is. > Hi, Can I have some comments from maintainers whether autorelabeling can be enabled in buildroot or not, and what would be the preferred way? It seems to me that I can propose a new init script for policycoreutils package that check for the autorelabel file and trigger the missing commands. Would that be a good idea? Best regards. José. [-- Attachment #1.2: Type: text/html, Size: 2429 bytes --] [-- Attachment #2: Type: text/plain, Size: 156 bytes --] _______________________________________________ buildroot mailing list buildroot@lists.buildroot.org https://lists.buildroot.org/mailman/listinfo/buildroot ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2021-09-03 6:54 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-08-19 9:29 [Buildroot] [PATCH v2] package/libselinux: Add autorelabel for first boot José Pekkarinen 2021-08-19 21:05 ` Yann E. MORIN 2021-08-20 12:19 ` José Pekkarinen 2021-08-20 19:15 ` Yann E. MORIN 2021-08-20 19:16 ` Yann E. MORIN 2021-08-23 5:43 ` José Pekkarinen 2021-08-23 14:19 ` [Buildroot] [External] " Weber, Matthew L Collins via buildroot 2021-08-25 11:33 ` José Pekkarinen 2021-09-03 6:53 ` José Pekkarinen
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.