All of lore.kernel.org
 help / color / mirror / Atom feed
From: "José Pekkarinen" <jose.pekkarinen@unikie.com>
To: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: "Weber, Matthew L Collins" <Matthew.Weber@collins.com>,
	Adam Duskett <aduskett@gmail.com>,
	buildroot@buildroot.org
Subject: Re: [Buildroot] [PATCH v2] package/libselinux: Add autorelabel for first boot
Date: Mon, 23 Aug 2021 08:43:54 +0300	[thread overview]
Message-ID: <CAJPV9Mo-6jFQb=hOGANwr6aD7NSzobYPk_kr+HCb=HuYBODzoA@mail.gmail.com> (raw)
In-Reply-To: <20210820191656.GS27036@scaer>


[-- 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

  reply	other threads:[~2021-08-23  5:44 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAJPV9Mo-6jFQb=hOGANwr6aD7NSzobYPk_kr+HCb=HuYBODzoA@mail.gmail.com' \
    --to=jose.pekkarinen@unikie.com \
    --cc=Matthew.Weber@collins.com \
    --cc=aduskett@gmail.com \
    --cc=buildroot@buildroot.org \
    --cc=yann.morin.1998@free.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.