From: Paul Moore <paul@paul-moore.com>
To: Stephen Smalley <stephen.smalley.work@gmail.com>
Cc: Ondrej Mosnacek <omosnace@redhat.com>,
linux-security-module@vger.kernel.org, selinux@vger.kernel.org
Subject: Re: [PATCH] security: fix the logic in security_inode_getsecctx()
Date: Tue, 30 Jan 2024 11:31:23 -0500 [thread overview]
Message-ID: <CAHC9VhQ5rbeejGQa5G_Qw0X5oM89Z60kRaSFOuqOhquidZ6GFg@mail.gmail.com> (raw)
In-Reply-To: <CAEjxPJ4bUoJNhjGAdrPAuHQr3DvK-hLRwt8xUS1tuZgqx3sJVw@mail.gmail.com>
On Tue, Jan 30, 2024 at 10:44 AM Stephen Smalley
<stephen.smalley.work@gmail.com> wrote:
> On Mon, Jan 29, 2024 at 4:56 PM Paul Moore <paul@paul-moore.com> wrote:
> >
> > On Mon, Jan 29, 2024 at 2:49 PM Stephen Smalley
> > <stephen.smalley.work@gmail.com> wrote:
> > > unix_socket test is failing because type_transition rule is not being
> > > applied to newly created server socket, leading to a denial when the
> > > client tries to connect. I believe that once worked; will see if I can
> > > find the last working kernel.
> >
> > If we had a socket type transition on new connections I think it would
> > have been a *long* time ago. I don't recall us supporting that, but
> > it's possible I've simply forgotten.
> >
> > That isn't to say I wouldn't support something like that, it could be
> > interesting, but we would want to make sure it applies to all
> > connection based sockets and not just AF_UNIX. Although for the vast
> > majority of users it would probably only be useful for AF_UNIX as you
> > would need a valid peer label to do a meaningful transition.
>
> Sorry, I probably wasn't clear. I mean that the Unix socket files are
> NOT being labeled in accordance with the type_transition rules in
> policy. Which does work on local file systems and used to work on NFS,
> so this is a regression at some point (but not new to Ondrej's patch).
Ah, gotcha.
I guess I'm not too surprised, the sock/socket/inode labeling and
duplication has always been very awkward and it wouldn't surprise me
if we inadvertently broke something over the years. Tracking down the
source of the breakage is good, but if that is taking too long (I can
only imagine how long that might take), I would be happy with a fix
with a number of comment additions warning future devs against
changing the relevant code.
--
paul-moore.com
next prev parent reply other threads:[~2024-01-30 16:31 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-26 10:44 [PATCH] security: fix the logic in security_inode_getsecctx() Ondrej Mosnacek
2024-01-26 14:32 ` Ondrej Mosnacek
2024-01-26 15:03 ` Stephen Smalley
2024-01-26 16:04 ` Stephen Smalley
2024-01-26 17:15 ` Ondrej Mosnacek
2024-01-29 19:48 ` Stephen Smalley
2024-01-29 21:55 ` Paul Moore
2024-01-30 15:44 ` Stephen Smalley
2024-01-30 16:31 ` Paul Moore [this message]
2024-01-26 16:36 ` Casey Schaufler
2024-01-26 22:18 ` Paul Moore
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=CAHC9VhQ5rbeejGQa5G_Qw0X5oM89Z60kRaSFOuqOhquidZ6GFg@mail.gmail.com \
--to=paul@paul-moore.com \
--cc=linux-security-module@vger.kernel.org \
--cc=omosnace@redhat.com \
--cc=selinux@vger.kernel.org \
--cc=stephen.smalley.work@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).