On Mon, Aug 26, 2013 at 9:22 AM, William Roberts <[email protected]>wrote:
> I started a thread with Stephen about implementing a way to adjust the > sensitivity portion of the MLS field in seapp_contexts. We have differing > ideologies on the implementation (I should have put this public from day > one): > > Below is the thread in detail, Ill summarize here though: > > Goal: > Given a policy that supports multiple sensitivities, be able to place apps > in different sensitivities while preserving a way to maintain the categorie > assignments as originally designed. > > Constraints: > Backwards compatible > > Implementation 1: > > We keep the level and levelFrom keywords mutually exclusive, as is the > current design. > > We allow the following expressions in the level keyword: > 1. level = <cats> > 2. level = <sens:cats> > 3. level = keyword > 4. level = <sens:cats> > > Pros: > 1. We could actually deprecate level from > 2. Reduces the amount of output selectors, or minimally keeps it the same. > 3. allows us to set a sens and still preserve category mappings > > Cons: > 1. Adds complexity to the level keyword > > Implementation 2: > We add a new sens category > Id be more ok with this approach if level was cats. And adding cats now would be an additional thing to remember based on history. sens=s0 cats=app is a bit more clear then sens=s1 level=app > > Sense would be a new field that can work with either level OR levelFrom > but not Both (XOR) > > in this case doing: > sens=s1 > level=c0,c87 > > would result in s1:c0,c87 > > doing: > sens=s1 > levelFrom=app > > s1:(app cat mapping) > > Pros: > 1. allows us to set a sens and still preserve category mappings > 2. Keeps level usage exactly the same > > Cons: > 1. adds a new output selector, which means more of specified sens over > unspecified sens...etc > > > So the point of this is, what do people prefer and why, and what other > things should be considered? > > Bill > > ---------- Forwarded message ---------- > From: Stephen Smalley <[email protected]> > Date: Mon, Aug 26, 2013 at 7:55 AM > Subject: Re: Multiple sensitivities > To: William Roberts <[email protected]> > > > Yep, that's what I would have preferred. > > On 08/26/2013 10:52 AM, William Roberts wrote: > > I don't know why I wanted only internal discussion, if your willing we > can > > move this publicly and let others chime in. > > > > > > On Mon, Aug 26, 2013 at 7:42 AM, William Roberts > > <[email protected]>wrote: > > > >> It keeps full backwards compatibility and minimizes selectors, the last > >> thing we need is another variable in that config. When C supported > >> anonymous structs they detected it implicitly... Not through another > >> keyword. > >> On Aug 26, 2013 10:37 AM, "Stephen Smalley" <[email protected]> wrote: > >> > >>> I don't see it. And I do want to preserve full compatibility, > >>> especially as the current syntax has now officially shipped in Android > >>> 4.3. > >>> > >>> On 08/26/2013 10:35 AM, William Roberts wrote: > >>>> Its one more addition do the outputs... That can be avoided. I think > it > >>>> keeps the configuration more compact. The parsing is not that hard. > >>>> On Aug 26, 2013 10:23 AM, "Stephen Smalley" <[email protected]> > wrote: > >>>> > >>>>> I don't quite see why. Benefit is full backward compatibility, and > >>> very > >>>>> simple parsing code for the new functionality (and zero impact on the > >>>>> rest of the code). > >>>>> > >>>>> On 08/26/2013 10:19 AM, William Roberts wrote: > >>>>>> I thought about that... But I think it makes it less usable. > >>>>>> On Aug 26, 2013 10:09 AM, "Stephen Smalley" <[email protected]> > >>> wrote: > >>>>>> > >>>>>>> Simplest approach would appear to be to just leave level and > >>> levelFrom > >>>>>>> alone, add a new sens= output selector, which if specified, sets > the > >>>>>>> sensitivity value accordingly while still honoring levelFrom for > >>>>>>> category setting. sens= would be exclusive of level=, but not of > >>>>>>> levelFrom=. > >>>>>>> > >>>>>>> On 08/23/2013 11:00 PM, William Roberts wrote: > >>>>>>>> I was thinking of what the implementation might be: > >>>>>>>> > >>>>>>>> one of two approaches: > >>>>>>>> we switch level and levelFrom to sens and cats > >>>>>>>> > >>>>>>>> if sens is unspecified, then the zygotes context is used > >>>>>>>> if sense is sepecified, it is used at the sesitivity > >>>>>>>> if cats is one of the already reserved _app, etc, then it works as > >>>>>>>> originally designed, appending to the mls string > >>>>>>>> if cats is not on the reserved strings, then it treats it as a raw > >>>>>>> category > >>>>>>>> and appends it to the mls string > >>>>>>>> > >>>>>>>> The other implementation approach is we only use level, where you > >>> could > >>>>>>> to > >>>>>>>> do this: > >>>>>>>> level=s0:c4 > >>>>>>>> level=s1:_app > >>>>>>>> level=_app > >>>>>>>> > >>>>>>>> .... > >>>>>>>> > >>>>>>>> and so forth. We leave leavelFrom there, and the existing if/else > >>>>> between > >>>>>>>> level and levelFrom is preserved (keep backwards compatibility) > and > >>> we > >>>>>>>> increase the logic in the level section to handle > >>>>>>>> the additional complexity, which is also backwards compatible. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> On Fri, Aug 23, 2013 at 6:25 PM, William Roberts > >>>>>>>> <[email protected]>wrote: > >>>>>>>> > >>>>>>>>> What would be a way to preserve the category pair form LevelFrom > >>>>> whilst > >>>>>>>>> also setting a sensitivity? > >>>>>>>>> > >>>>>>>>> I see right now the sensitivity is selected by getcon() on > zygotes > >>>>>>> process > >>>>>>>>> context, and then adjusting the fields from there. > >>>>>>>>> > >>>>>>>>> Im not really trying to go classified, but would like to be able > to > >>>>> make > >>>>>>>>> use of them for some > >>>>>>>>> more fine grained control, and not much with the category pairs > (I > >>>>> like > >>>>>>>>> those). > >>>>>>>>> > >>>>>>>>> Id like to be able so label things as s1, and then let the mls > >>>>>>> constraints > >>>>>>>>> work. So for instance, > >>>>>>>>> if I labeled network traffic coming in off a port as packet:s1 > only > >>>>> apps > >>>>>>>>> running in s1:(cat pair) > >>>>>>>>> can access it. > >>>>>>>>> > >>>>>>>>> I obviously had to jack the MLS_SENS up to 2, which also begs > >>> should > >>>>> we > >>>>>>>>> make this a ?= ? > >>>>>>>>> > >>>>>>>>> -- > >>>>>>>>> Respectfully, > >>>>>>>>> > >>>>>>>>> William C Roberts > >>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>>> > >>>> > >>> > >>> > > > > > > > > > -- > Respectfully, > > William C Roberts > > -- Respectfully, William C Roberts
