Re: [PATCH v2] default_range glblub implementation

[Paul Moore <paul@paul-moore.com>]

On Thu, Aug 29, 2019 at 1:11 PM Joshua Brindle
<joshua.brindle@crunchydata.com> wrote:
> On Thu, Aug 29, 2019 at 12:59 PM Paul Moore <paul@paul-moore.com> wrote:
> > On Thu, Aug 29, 2019 at 9:29 AM Joshua Brindle
> > <joshua.brindle@crunchydata.com> wrote:
> > > On Wed, Aug 28, 2019 at 6:31 PM Paul Moore <paul@paul-moore.com> wrote:
> > > > On Wed, Aug 28, 2019 at 4:43 PM Joshua Brindle
> > > > <joshua.brindle@crunchydata.com> wrote:
> > > > >
> > > > > A policy developer can now specify glblub as a default_range default and
> > > > > the computed transition will be the intersection of the mls range of
> > > > > the two contexts.
> > > > >
> > > > > The glb (greatest lower bound) lub (lowest upper bound) of a range is calculated
> > > > > as the greater of the low sensitivities and the lower of the high sensitivities
> > > > > and the and of each category bitmap.
> > > > >
> > > > > This can be used by MLS solution developers to compute a context that satisfies,
> > > > > for example, the range of a network interface and the range of a user logging in.
> > > > >
> > > > > Some examples are:
> > > > >
> > > > > User Permitted Range | Network Device Label | Computed Label
> > > > > ---------------------|----------------------|----------------
> > > > > S0-S1:c0.c12         | S0                   | S0
> > > > > S0-S1:c0.c12         | S0-S1:c0.c1024       | S0-S1:c0.c12
> > > > > S0-S4:c0.c512        | S1-S1:c0.c1024       | S1-S1:c0.c512
> > > > > S0-S16:c0,c2         | S4-S6:c0.c128        | S4-S6:c0,c2
> > > > > S0-S4                | S2-S6                | S2-S4
> > > > > S0-S4                | S5-S8                | INVALID
> > > > > S5-S8                | S0-S4                | INVALID
> > > > > S6:c0,c2-S7:c4,c5    | S0:c2,c4-S6:c5.c100  | S6:c2-S6:c5
> > > > >
> > > > > Signed-off-by: Joshua Brindle <joshua.brindle@crunchydata.com>
> > > > > ---
> > > > >  security/selinux/include/security.h |  3 ++-
> > > > >  security/selinux/ss/context.h       | 28 ++++++++++++++++++++++++++++
> > > > >  security/selinux/ss/ebitmap.c       | 18 ++++++++++++++++++
> > > > >  security/selinux/ss/ebitmap.h       |  1 +
> > > > >  security/selinux/ss/mls.c           |  2 ++
> > > > >  security/selinux/ss/policydb.c      |  5 +++++
> > > > >  security/selinux/ss/policydb.h      |  1 +
> > > > >  7 files changed, 57 insertions(+), 1 deletion(-)
> > > >
> > > > You incorporated some feedback from the v1 patch, but you ignored
> > > > some, can you explain why?
> > > >
> > >
> > > I apologize, I missed a couple C++ style comments, I'll fix those and
> > > resend, was there anything else? I thought I addressed all of the
> > > technical concerns.
> >
> > My biggest concern wasn't really the style nits (although please do
> > fix those), but rather the guts of ebitmap_and() and the use of
> > ebitmap_get_bit() instead of something a bit more efficient.  Here is
> > my original comment:
> >
> >   "Beyond that, since this is an AND operation, could we make better
> >    use of things like find_first_bit()/ebitmap_start_positive()/
> >    ebitmap_next_positive() to skip along one of the bitmaps instead
> >    of needing to call ebitmap_get_bit() for each bit?  I imagine it
> >    would be quicker that way."
> >
>
> I used ebitmap_for_each_positive_bit() for the outer loop which uses
> ebitmap_start_positive() and ebitmap_next_positive().

Sorry, my mistake.  Your implementation wasn't quite what I was
expecting and on quick glance it looked similar to your previous
effort so I assumed it hadn't changed.  The v2 variant should be fine.

> I suppose I could try to track both lists at the same time and AND the
> bitmaps when the startbit is the same but I don't expect this to
> really be any kind of bottleneck.

-- 
paul moore
www.paul-moore.com