> On May 8, 2017, at 5:32 AM, Dominick Grift <dac.overr...@gmail.com> 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.
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
