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"domain" is a reference policy type attributeOne 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 SPANOr 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.
Thanks - Karl
|
