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