On Mon, May 08, 2017 at 03:36:21PM -0400, Karl MacMillan wrote:
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.
We’ve not tested it for Android policies so I’m sure there will be some breakage. But I hope it will be fixed to work by us or someone soon.
Thank you for giving me your opinion. At least now I know where I stand.
Where you stand? I’m not certain what you mean and was not trying to say something about you personally.
I was not familiar with DSSP before (I’ve not done much with SELinux for a while), but Josh pointed it out to me. From looking at it very briefly and thinking through the assumptions in SPAN my guess is that it would take very few changes to make SPAN work with DSSP, even the source policy stuff (which, honestly, is just a very small part mainly useful for diffing constraints).
And as a side note - it’s nice to see someone trying to write a policy from scratch in CIL. Do you have a “domain” attribute or at least a similar concept?
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.
I’m curious what you mean by “only works to some extent”. Any bug reports would be welcome.
And if you mean specifically in the context of DSSP, like I said I bet the changes would be minimal. So if you are interested in giving it a try I’ll be happy to look at the changes needed and give you a hand.
Thanks - Karl
