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." > > 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
