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

José Pekkarinen jose.pekkarinen at unikie.com
Mon Aug 23 05:43:54 UTC 2021


On Fri, Aug 20, 2021 at 10:17 PM Yann E. MORIN <yann.morin.1998 at 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 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.
>

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é.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20210823/6ebb98f7/attachment.html>


More information about the buildroot mailing list