On Mon, Jul 6, 2020 at 9:23 AM Stephen Smalley <stephen.smalley.work@xxxxxxxxx> wrote: > > On Mon, Jun 29, 2020 at 3:59 PM Mike Palmiotto > <mike.palmiotto@xxxxxxxxxxxxxxx> wrote: <snip> > > > > Or would it be simpler to just > > update `avc_has_perm_noaudit` to query sestatus for enforcing, rather > > than refer to `avc_enforcing`? > > The current AVC interface allows an object manager to explicitly set > the enforcing mode and ignore the underlying system enforcing mode, > such that one can have an object manager running permissive while the > kernel and other userspace object managers running enforcing for > development purposes. So we'd still need to support that scenario I > believe. That said, providing an option to use sestatus instead of > netlink and potentially making that the default going forward might be > of interest as long as it doesn't break compatibility. The sestatus > code already falls back to netlink if the kernel doesn't support the > status page. > > > > > 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? > > I haven't looked closely but would guess that we could use the same callbacks. This all sounds good to me. I'll make sure the existing functionality remains unchanged and see if I can leverage the current callbacks. > > > 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? > > As long as the final state is correct, I don't think so, but I'm not > sure what scenario you are considering. I was likely just getting wrapped up in semantics. We really only care that seqno is incremented once a state is processed. Thanks for the feedback. I should be able to send a patch sometime this week. -- Mike Palmiotto https://crunchydata.com
