On Mon, May 08, 2017 at 03:36:21PM -0400, Karl MacMillan wrote:
>
> > On May 8, 2017, at 5:32 AM, Dominick Grift <dac.override@xxxxxxxxx> wrote:
> >
> > On Mon, May 08, 2017 at 10:55:55AM +0200, Dominick Grift wrote:
> >> On Sun, May 07, 2017 at 03:42:50PM -0400, Joshua Brindle wrote:
> >>> Dominick Grift wrote:
> >>>> On Sun, May 07, 2017 at 11:22:00AM -0400, Joshua Brindle wrote:the
> >>>>> Dominick Grift wrote:
> >>>>> <snip>
> >>>>>
> >>>>>> The idea is nice, unfortunately its inflexible and it has hard-references to reference policy all-over. It has potential but it is still rough.
> >>>>>>
> >>>>> Of course, it is an analysis of a refpolicy-based policy. If you want to
> >>>>> analyze a different policy (e.g., Android or home-rolled) you will have to
> >>>>> change out all of the type sets, etc.
> >>>>>
> >>>>> You can't make a magic generic analysis script without knowing how key parts
> >>>>> of the system work and what types are associated with those components.
> >>>>
> >>>> What do you mean? that for example that hard-coded array of "trusted" types. Is that not just redundant.
> >>>>
> >>>
> >>> you mean the example trusted types? I'm not sure I understand your concern.
> >>>
> >>>> Can't i just create that array myself and use it to exlude rules with types in that array? That was one does not have to hard-code it.
> >>>>
> >>>
> >>> It is python, you can do anything you want. The example notebook is a
> >>> starting point, anyone doing an analysis would probably make major changes
> >>> for their analysis, which is the point. You modify the notebook to build a
> >>> usable analysis between the starting policy and the policy you are
> >>> analyzing.
> >>>
> >>> I've thought about trying this on an Android policy but haven't made it a
> >>> priority.
> >>>
> >>>> Also with regard to hardcoding the refpolicy file system (ps.load_policy_source). I mean if youre just going to `grep -r` then why do we have to assume anything there and hard code file suffixed, directory structures etc etc?
> >>>
> >>>
> >>
> >> ahh.. sorry. I just noticed that it can be overriden:
> >>
> >> p, ps, bp, bps = se.load_policies_from_config("policy_paths.config")
> >>
> >> so i suppose i should be able to add that file to the notebook dir and specify my own paths.
> >>
> >> although that still doesnt deal with any file suffixes? (.cil)
> >
> >
> > take for example: https://github.com/QuarkSecurity/SPAN/blob/master/span/span.py#L331 <https://github.com/QuarkSecurity/SPAN/blob/master/span/span.py#L331>
> >
> > "domain" is a reference policy type attribute
> >
> > One should expand on the "policy_paths.config" concept and allow us, via configuration files, to override all the variables (attributes, suffixes, paths, identifiers, etc)
> >
> > So that the variables can we adjusted without the need to reinstall/recompile a modified SPAN
> >
> > Or just rename to RPAN (reference policy analysis notebook)
>
> I think it’s best to think of these as having three basic layers:
>
> 1. Basic tools for SELinux policy analysis in Jupyter - these are usable for any policy and make no assumptions about the presence of any types, attributes, object classes, or permissions. So things like the rule searching and information flow analysis fit into this group. This is a large part of the value of SPAN.
>
> 2. Higher-level policy analysis methods - these are things like the domain_types method and the domain / type summaries. These make some minimal assumptions about attributes like domain. I’ll just mention that these assumptions are very minimal and have been around for a _long_ time. Domain long pre-dates the reference policy, for example. More than attributes this layer is tied to the Linux object classes and permissions.
>
> 3. Example notebooks - the two example notebooks are just that - examples. They probably provide a useful starting point, but as Josh points out, should simply be modified for your specific use case.
>
> So the question, then, is should the second layer (the higher-level policy analysis methods) be made configurable. Honestly I think it would be more work than just creating your own versions for a policy that breaks the assumptions. To me, that’s the great advantage of this versus other analysis tools. It’s so simple to create quick tools that meet your needs. And given that the vast majority of Linux and Android systems meet the assumptions I think that this is a reasonable approach.
I don't think it will work with android. Some of it maybe but not all of it. for example the source functionality appends "modules" to the search path. So i suspect that will break that functionality for Android.
Thank you for giving me your opinion. At least now I know where I stand. I will not be able to leverage this solution to any significant extend, and the notebook and its depenedencies are pretty expensive to have just for something that only works to some extent.
Atleast this inspired me to implement policy for pip and notebook in my personal security policy. So it was not all in vain.
>
> Thanks - Karl
>
> >
> >>
> >> --
> >> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
> >> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02>
> >> Dominick Grift
> >
> >
> >
> > --
> > Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
> > https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02>
> > Dominick Grift
>
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
Attachment:
signature.asc
Description: PGP signature
