selinux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephen Smalley <stephen.smalley.work@gmail.com>
To: Ondrej Mosnacek <omosnace@redhat.com>
Cc: Petr Lautrbach <plautrba@redhat.com>,
	SElinux list <selinux@vger.kernel.org>,
	Paul Moore <paul@paul-moore.com>
Subject: Re: [RFC PATCH] selinux: runtime disable is deprecated, add some ssleep() discomfort
Date: Thu, 10 Sep 2020 10:54:38 -0400	[thread overview]
Message-ID: <CAEjxPJ6wViyeub1NMvTLjSaLRT2zu2sLap1+uVqVDtiSNnAVzA@mail.gmail.com> (raw)
In-Reply-To: <CAEjxPJ7n7irnx93xsNamWsuvoEaOQqDkgwPXJod8rrXUciOWng@mail.gmail.com>

On Thu, Sep 10, 2020 at 10:36 AM Stephen Smalley
<stephen.smalley.work@gmail.com> wrote:
>
> On Thu, Sep 10, 2020 at 9:31 AM Stephen Smalley
> <stephen.smalley.work@gmail.com> wrote:
> > 2) For cases where an error is returned by SELinux that is not already
> > governed by a selinux_initialized() or enforcing_enabled() check, we
> > just need to ensure that all such cases are gated by such a check. We
> > fixed that recently for the removexattr security.selinux case and
> > there were some earlier cases fixed with respect to setting labels
> > before policy load.  The specific concern raised in the thread
> > appeared to be due to denials silenced via dontaudit rules, which
> > won't happen if there is no policy loaded so I don't think that's
> > relevant.  There are other cases where SELinux might return an error
> > if a new case is introduced in another kernel subsystem without
> > updating SELinux to handle it, e.g. a new type for
> > selinux_perf_event_open(), a new obj_type in selinux_path_notify().
> > It would be better if we could introduce build-time guards to catch
> > these as we have done for e.g. new capabilities, new socket address
> > families, new netlink message types, in order to ensure that they are
> > always in sync.
>
> On second look, selinux_perf_event_open() is ok because the type
> values are specifically (and only) for the security hook, so anyone
> adding new PERF_SECURITY_* types should see the need to update the
> hook implementation too.  selinux_path_notify() case is different.

For selinux_path_notify(), there are in fact other fsnotify object
types defined in fsnotify_backend.h but
fs/notify/fanotify_user.c:do_fanotify_mark() only ever sets obj_type
that is later passed to the hook to one of the three values it handles
(inode, vfsmount, sb).  Since that could potentially change in the
future, we should likely change the security framework to define its
own set of SECURITY_NOTIFY_OBJ_TYPE_* values and have the hook callers
explicitly translate to one of those.

  reply	other threads:[~2020-09-10 14:59 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-02 12:47 [RFC PATCH] selinux: runtime disable is deprecated, add some ssleep() discomfort Paul Moore
2020-06-02 12:49 ` Paul Moore
2020-06-04 14:49   ` Stephen Smalley
2020-06-08 21:35     ` Paul Moore
2020-06-08 22:13       ` Stephen Smalley
2020-06-08 22:56         ` William Roberts
2020-06-10 14:03         ` Stephen Smalley
2020-06-10 14:11           ` Stephen Smalley
2020-06-11 13:29             ` Ondrej Mosnacek
2020-06-12 19:28               ` Paul Moore
2020-08-19 17:14                 ` Petr Lautrbach
2020-08-19 19:07                   ` Stephen Smalley
2020-08-19 19:16                     ` Stephen Smalley
2020-08-20 15:41                       ` Casey Schaufler
2020-08-20 16:58                       ` Stephen Smalley
2020-08-20 20:31                         ` Petr Lautrbach
2020-09-10 11:39                     ` Ondrej Mosnacek
2020-09-10 12:33                       ` Stephen Smalley
2020-09-23 18:32                         ` Paul Moore
2020-09-24 23:42                           ` Stephen Smalley
2020-09-10 13:31                       ` Stephen Smalley
2020-09-10 14:36                         ` Stephen Smalley
2020-09-10 14:54                           ` Stephen Smalley [this message]
2020-06-12 19:00             ` Paul Moore
2020-06-12 18:56         ` Paul Moore
2022-03-01 22:53 Paul Moore
2022-03-01 22:57 ` Paul Moore
2022-03-01 23:02 ` Casey Schaufler
2022-04-04 20:23 ` 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=CAEjxPJ6wViyeub1NMvTLjSaLRT2zu2sLap1+uVqVDtiSNnAVzA@mail.gmail.com \
    --to=stephen.smalley.work@gmail.com \
    --cc=omosnace@redhat.com \
    --cc=paul@paul-moore.com \
    --cc=plautrba@redhat.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 NNTP newsgroup(s).