On Thu, Aug 29, 2019 at 12:59 PM Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > > On Thu, Aug 29, 2019 at 9:29 AM Joshua Brindle > <joshua.brindle@xxxxxxxxxxxxxxx> wrote: > > On Wed, Aug 28, 2019 at 6:31 PM Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > > > On Wed, Aug 28, 2019 at 4:43 PM Joshua Brindle > > > <joshua.brindle@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx> > > > > --- > > > > 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(). 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. > > > For reference, here are my comments on your first patch: > > > * https://lore.kernel.org/selinux/CAHC9VhRXyRDjj3KJDHvA4ruJg6H+1kzFPzfA-PLZ-NqBicsLrw@xxxxxxxxxxxxxx/ > > -- > paul moore > www.paul-moore.com
