From: Stephen Smalley <stephen.smalley.work@gmail.com>
To: Paul Moore <paul@paul-moore.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 10:44:24 -0500 [thread overview]
Message-ID: <CAEjxPJ4bUoJNhjGAdrPAuHQr3DvK-hLRwt8xUS1tuZgqx3sJVw@mail.gmail.com> (raw)
In-Reply-To: <CAHC9VhSG14u5UUYiU6kUDt8jGMPkHAs67F_kc5Xt+w_P_zEovw@mail.gmail.com>
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).
next prev parent reply other threads:[~2024-01-30 15:44 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 [this message]
2024-01-30 16:31 ` Paul Moore
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=CAEjxPJ4bUoJNhjGAdrPAuHQr3DvK-hLRwt8xUS1tuZgqx3sJVw@mail.gmail.com \
--to=stephen.smalley.work@gmail.com \
--cc=linux-security-module@vger.kernel.org \
--cc=omosnace@redhat.com \
--cc=paul@paul-moore.com \
--cc=selinux@vger.kernel.org \
/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).