selinux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mike Palmiotto <mike.palmiotto@crunchydata.com>
To: selinux@vger.kernel.org
Subject: [RFC] userspace: netlink/sestatus feature parity
Date: Mon, 29 Jun 2020 15:40:05 -0400	[thread overview]
Message-ID: <CAMN686EVbRLAiti82aRqQUHLYERe7fSydgz1NVttZNHS74dkFQ@mail.gmail.com> (raw)

In looking at the userspace AVC netlink and sestatis code, I noticed
there are a few discrepancies between the two mechanisms. Considering
sestatus is intended (AFAICT) to be a swap-in replacement for netlink,
I'd expect all of the same code paths to be covered. This doesn't seem
to be the case.

One such difference is the handling of `setenforce` events in
`selinux_status_updated/setenforce()`. While netlink updates the
internal `avc_enforcing` state, `selinux_status_updated/setenforce()`
do not.

Any userspace object manager wishing to use sestatus with the internal
AVC is not guaranteed to have accurate state during calls to
`avc_has_perm_noaudit`, unless they reach out to netlink. sestatus was
initially implemented for use in sepgsql, which did not require use of
`avc_has_perm_noaudit`.

To more robustly support use of sestatus, I'm proposing that we
improve upon the sestatus code by having it update/reset AVC internal
state (avc_enforcing, for example) on status events.

Would such a patch be of interest? Or would it be simpler to just
update `avc_has_perm_noaudit` to query sestatus for enforcing, rather
than refer to `avc_enforcing`?

A few questions further questions in case this improvement is of interest:

1) Should there be separate callbacks for netlink counterparts in
sestatus, or is the existing infrastructure suitable for implementing
handling of those events?

2) With netlink we're guaranteed sequential processing of events. The
same is not true for mmap()'ed status updates. Do we care about the
order in which events are processed?

Thanks in advance,
-- 
Mike Palmiotto
https://crunchydata.com

             reply	other threads:[~2020-06-29 19:58 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-29 19:40 Mike Palmiotto [this message]
2020-07-06 13:23 ` [RFC] userspace: netlink/sestatus feature parity Stephen Smalley
2020-07-06 16:55   ` Mike Palmiotto

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=CAMN686EVbRLAiti82aRqQUHLYERe7fSydgz1NVttZNHS74dkFQ@mail.gmail.com \
    --to=mike.palmiotto@crunchydata.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).