All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Palmiotto <mike.palmiotto@crunchydata.com>
To: Stephen Smalley <stephen.smalley.work@gmail.com>
Cc: SElinux list <selinux@vger.kernel.org>
Subject: Re: [PATCH v4] libselinux: use kernel status page by default
Date: Fri, 31 Jul 2020 10:17:18 -0400	[thread overview]
Message-ID: <CAMN686E2M0jjh3s10qq=XzF63YpAgC2BQnqPwrLhLPh7XFvKAA@mail.gmail.com> (raw)
In-Reply-To: <CAEjxPJ5MW-QM34AwCaB2Zo1H=mDX+y9H5G3=tOSgz4pO5+fCkg@mail.gmail.com>

On Fri, Jul 24, 2020 at 4:25 PM Stephen Smalley
<stephen.smalley.work@gmail.com> wrote:
>
> On Fri, Jul 24, 2020 at 3:43 PM Mike Palmiotto
> <mike.palmiotto@crunchydata.com> wrote:
> >
> > On Fri, Jul 24, 2020 at 3:34 PM Mike Palmiotto
> > <mike.palmiotto@crunchydata.com> wrote:
> > >
> > > On Fri, Jul 24, 2020 at 2:26 PM Stephen Smalley
> > > <stephen.smalley.work@gmail.com> wrote:
> > > >
> > > > On Fri, Jul 24, 2020 at 12:23 PM Mike Palmiotto
> > > > <mike.palmiotto@crunchydata.com> wrote:
> > > > >
> > > > > On Fri, Jul 24, 2020 at 12:09 PM Stephen Smalley
> > > > > <stephen.smalley.work@gmail.com> wrote:
> > > > > >
> > > > > > On Fri, Jul 24, 2020 at 11:48 AM Stephen Smalley
> > > > > > <stephen.smalley.work@gmail.com> wrote:
> > > > > > >
> > > > > > > On Fri, Jul 24, 2020 at 11:34 AM Stephen Smalley
> > > > > > > <stephen.smalley.work@gmail.com> wrote:
> > > > > > > >
<snip>
> > > > > > So, options would appear to be:
> > > > > > 1) Drop the usage of avc_using_threads altogether, i.e. even if the
> > > > > > caller provided a thread callback, don't create another thread and
> > > > > > just call selinux_status_updated() on every avc_has_perm_noaudit()
> > > > > > unless avc_app_main_loop is set.  Rationale: dbus-daemon was only
> > > > > > using threads to avoid the overhead of avc_netlink_check_nb() on every
> > > > > > avc_has_perm_noaudit() call, and we've eliminated that via use of
> > > > > > sestatus, hence we don't need to create a separate thread at all.
> > > > > > -or-
> > > > > > 2) If using threads, then create the netlink socket during avc_init
> > > > > > and keep using the netlink loop for the thread.  This preserves the
> > > > > > blocking behavior.
> > > > > >
> > > > > > #1 seems more optimal to me and gets rid of threading for dbus-daemon,
> > > > > > which was something they didn't like anyway.
> > > > >
> > > > > Perhaps this is misguided, but it seems like avc_init is deprecated
> > > > > and along with it the ability to even set a custom thread callback.
> > > > > IOTW there does not appear to be a mechanism to set a thread callback
> > > > > while using avc_open (only avc_init). Perhaps we can just get rid of
> > > > > the default callback for avc_open and allow the (deprecated) avc_init
> > > > > to continue using it as it does?
> > > > >
> > > > > Is this basically what you were proposing for #2? I think I'd be more
> > > > > inclined to go with that approach, in case userspace object managers
> > > > > are doing other things in their thread callback.
> > > >
> > > > I think that's the same as #2 if I understood you currently.  That's
> > > > fine if you prefer it.
> > > > So then programs using avc_init() with non-NULL thread callbacks
> > > > (hence avc_using_threads == 1) will still create the netlink socket
> > > > and start a thread running avc_netlink_loop().  And programs using
> > > > avc_netlink_acquire_fd() will create the netlink socket if not already
> > > > created and can use it however they want.  Everything else will move
> > > > to using the status page.
> > >
> > > What do you think about moving avc_create_thread call (if
> > > avc_using_threads is set) into avc_netlink_acquire_fd().
> > >
> > > That way, if the caller is using avc_init with a create_thread
> > > callback, they can get their netlink socket and create the netlink
> > > thread and everything will function as before. In theory, this would
> > > also work for the sestatus netlink fallback.
> >
> > Alternatively, we could just move the thread creation into the
> > sestatus fallback, since, as you pointed out, the only reason for
> > creating a thread would be to avoid the avc_netlink_check_nb()
> > overhead.
>
> avc_netlink_acquire_fd() isn't called by dbus-daemon in its current
> release used in Fedora/RHEL.
> So adding it there won't help.  We could add it to
> selinux_status_open().  Just need to make sure we don't call
> avc_netlink_open() twice there (it is already called in the fallback
> case) or make it safe to do so.

I've given this a bit more thought, and I'm actually leaning toward
your option #1, Stephen.

Doing away with netlink threads (for non-fallback) should be fine. The
only real change in functionality would be handling of status events
on the next access check, rather than immediately in the thread.

I have a patch repaired to use this approach (and properly handle avc
threads for the sestatus fallback case). I just need to
rebase/review/re-test before submitting.

Thanks for all of the feedback and sorry for the delay.



-- 
Mike Palmiotto
https://crunchydata.com

      reply	other threads:[~2020-07-31 14:17 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-24 14:13 [PATCH v4] libselinux: use kernel status page by default Mike Palmiotto
2020-07-24 15:34 ` Stephen Smalley
2020-07-24 15:48   ` Stephen Smalley
2020-07-24 16:09     ` Stephen Smalley
2020-07-24 16:23       ` Mike Palmiotto
2020-07-24 16:29         ` Mike Palmiotto
2020-07-24 18:25         ` Stephen Smalley
2020-07-24 19:34           ` Mike Palmiotto
2020-07-24 19:42             ` Mike Palmiotto
2020-07-24 20:25               ` Stephen Smalley
2020-07-31 14:17                 ` Mike Palmiotto [this message]

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='CAMN686E2M0jjh3s10qq=XzF63YpAgC2BQnqPwrLhLPh7XFvKAA@mail.gmail.com' \
    --to=mike.palmiotto@crunchydata.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 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.