Re: Announcing SPAN: SELinux Policy Analysis Notebook

[Dominick Grift]

On Mon, May 08, 2017 at 11:47:14PM +0200, Dominick Grift wrote:
> On Mon, May 08, 2017 at 10:40:53PM +0200, Dominick Grift wrote:
> > On Mon, May 08, 2017 at 04:09:16PM -0400, Karl MacMillan wrote:
> > > 
> > > > On May 8, 2017, at 3:49 PM, Dominick Grift  
> > > > wrote:
> > > > 
> > > > 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 didnt take it personal, That is not what I meant. To me SELinux is bigger 
> > then any single policy be it refpolicy, sepolicy, or dssp
> > The perfect tool would support any policy (setools goes a long way there). 
> > From your comments I sensed that you might not fully agree with that or 
> > that you might not have the ambition for SPAN to be perfect.
> > What I am saying is that after your comment I no longer have any illusions 
> > that SPAN will ever be perfect (or close to perfect)
> > 
> > > 
> > > 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?
> > 
> > Sure, but i cannot use "domain" for this because DSSP leverages namespaces. 
> > The equivalent in DSSP is "subj.subj_type_attribute"
> > 
> > So if the configuration file would have something like:
> > 
> > # process_types = domain
> > 
> > Then i would be happy because then i could edit it like:
> > 
> > process_types = subj.subj_type_attribute
> > 
> > > 
> > > > 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.
> > 
> > Let me rephrase then: "not to the fullest extent"
> > 
> > But you gave me the impression that not all bug reports would be "welcome" 
> > when you said: "the vast majority of Linux and Android systems meet the 
> > assumptions I think that this is a reasonable approach."
> > 
> > > 
> > > And if you mean specifically in the context of DSSP, like I 

Re: Announcing SPAN: SELinux Policy Analysis Notebook

[Dominick Grift]

On Mon, May 08, 2017 at 10:40:53PM +0200, Dominick Grift wrote:
> On Mon, May 08, 2017 at 04:09:16PM -0400, Karl MacMillan wrote:
> > 
> > > On May 8, 2017, at 3:49 PM, Dominick Grift  wrote:
> > > 
> > > 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 didnt take it personal, That is not what I meant. To me SELinux is bigger 
> then any single policy be it refpolicy, sepolicy, or dssp
> The perfect tool would support any policy (setools goes a long way there). 
> From your comments I sensed that you might not fully agree with that or that 
> you might not have the ambition for SPAN to be perfect.
> What I am saying is that after your comment I no longer have any illusions 
> that SPAN will ever be perfect (or close to perfect)
> 
> > 
> > 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?
> 
> Sure, but i cannot use "domain" for this because DSSP leverages namespaces. 
> The equivalent in DSSP is "subj.subj_type_attribute"
> 
> So if the configuration file would have something like:
> 
> # process_types = domain
> 
> Then i would be happy because then i could edit it like:
> 
> process_types = subj.subj_type_attribute
> 
> > 
> > > 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.
> 
> Let me rephrase then: "not to the fullest extent"
> 
> But you gave me the impression that not all bug reports would be "welcome" 
> when you said: "the vast majority of Linux and Android systems meet the 
> assumptions I think that this is a reasonable approach."
> 
> > 
> > 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.
> 
> I agree, and ive said that when I said: "a few rough edges" Its close the 
> usable with DSSP. It just needs to deal 

Re: Announcing SPAN: SELinux Policy Analysis Notebook

[Dominick Grift]

On Mon, May 08, 2017 at 04:09:16PM -0400, Karl MacMillan wrote:
> 
> > On May 8, 2017, at 3:49 PM, Dominick Grift  wrote:
> > 
> > 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 didnt take it personal, That is not what I meant. To me SELinux is bigger 
then any single policy be it refpolicy, sepolicy, or dssp
The perfect tool would support any policy (setools goes a long way there). From 
your comments I sensed that you might not fully agree with that or that you 
might not have the ambition for SPAN to be perfect.
What I am saying is that after your comment I no longer have any illusions that 
SPAN will ever be perfect (or close to perfect)

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

Sure, but i cannot use "domain" for this because DSSP leverages namespaces. The 
equivalent in DSSP is "subj.subj_type_attribute"

So if the configuration file would have something like:

# process_types = domain

Then i would be happy because then i could edit it like:

process_types = subj.subj_type_attribute

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

Let me rephrase then: "not to the fullest extent"

But you gave me the impression that not all bug reports would be "welcome" when 
you said: "the vast majority of Linux and Android systems meet the assumptions 
I think that this is a reasonable approach."

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

I agree, and ive said that when I said: "a few rough edges" Its close the 
usable with DSSP. It just needs to deal with some of the current assumptions:

ill point out some:

1. return self.grep(name, "*.te", self.modules_path) # what about .cil suffixed 
files?
2. return self.find_def("attribute " + name) # in CIL this is typeattribute
3. return self.grep(type_name, "*.fc", 

Re: Announcing SPAN: SELinux Policy Analysis Notebook

[Karl MacMillan]

> On May 8, 2017, at 3:49 PM, Dominick Grift  wrote:
> 
> 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

> 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=0x3B6C5F1D2C7B6B02 
  
 >
 Dominick Grift
>>> 
>>> 
>>> 
>>> -- 
>>> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
>>> https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 
>>>  
>>> >> >
>>> Dominick Grift
>> 
> 
> -- 
> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
> https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 
> 
> Dominick Grift

Re: Announcing SPAN: SELinux Policy Analysis Notebook

[Dominick Grift]

On Mon, May 08, 2017 at 03:36:21PM -0400, Karl MacMillan wrote:
> 
> > On May 8, 2017, at 5:32 AM, Dominick Grift  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:
> > 
> > 
> >> 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 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 

Re: Announcing SPAN: SELinux Policy Analysis Notebook

[Karl MacMillan]

> On May 7, 2017, at 3:53 PM, Dominick Grift  wrote:
> 
> 
> Python is not really my thing so i will have to get used to it and explore my 
> options
> 
> Its a cool module, has a few rough edges (but thats to be expected from 
> v0.0.0)
> 

So far I’ve seen your concerns over installation and reference policy 
assumptions. Any other “rough edges” that you’ve seen?

Thanks - Karl

>>> 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?
>> 
>> 
> 
> -- 
> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
> https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 
> 
> Dominick Grift

Re: Announcing SPAN: SELinux Policy Analysis Notebook

[Karl MacMillan]

> On May 8, 2017, at 3:32 PM, Dominick Grift  wrote:
> 
> On Mon, May 08, 2017 at 03:23:06PM -0400, Karl MacMillan wrote:
>>> 
>> 
>> Thanks for making the Fedora SPEC. 
>> 
>> I know it’s a topic of great debate, but there are some nice things about 
>> just sticking with the Python tools for dependency management for upstream. 
>> Mainly because it’s portable and helps get the latest versions (which is 
>> nice for fast moving projects like Jupyter notebook and Pandas).
> 
> Yes it is pretty cool (pip) and this event actually prompted me to make pip 
> work in my environment. However for me in this case it is really not an 
> option. Its nice for simple python modules but python programs such as 
> notebook need permissions that i do not associate will login users shells, 
> and i dont support confining applications installed to $HOME. notebook needs 
> permissions like execmem, needs network connectivity and a few other things 
> that i do not allow my user login shells. So I have to make this work 
> system-wide and I wanted the benefit of being able to manage/keep track off 
> what i install system-wide
> 

Interesting. I’ll just note that it’s perfectly possible to run Jupyter 
Notebook as a server and connect to it via a web-browser. So it would be simple 
to run Jupyter in a container or VM, which might make containing it easier. 
Personally, I just run this on a development system that’s not so locked down.

Karl

>> 
>> Karl
>> 
>> 
 
> 
>> 
>> -- 
>> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
>> https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02
>> Dominick Grift
> 
> 
> 
> -- 
> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
> https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02
> Dominick Grift
 
 
 
 -- 
 Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
 https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 
 
 Dominick Grift
>>> 
>>> 
>>> 
>>> -- 
>>> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
>>> https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 
>>>  
>>> >> >
>>> Dominick Grift
>> 
> 
> -- 
> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
> https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 
> 
> Dominick Grift

Re: Announcing SPAN: SELinux Policy Analysis Notebook

[Karl MacMillan]

> On May 8, 2017, at 5:32 AM, Dominick Grift  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:
> 
> 
>> 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 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=0x3B6C5F1D2C7B6B02 
>> 
>> Dominick Grift
> 
> 
> 
> -- 
> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
> https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 
> 
> Dominick Grift

Re: Announcing SPAN: SELinux Policy Analysis Notebook

[Dominick Grift]

On Mon, May 08, 2017 at 03:23:06PM -0400, Karl MacMillan wrote:
> 
> > On May 7, 2017, at 5:39 AM, Dominick Grift  wrote:
> > 
> > On Sat, May 06, 2017 at 07:19:20PM +0200, Dominick Grift wrote:
> >> On Sat, May 06, 2017 at 06:19:56PM +0200, Dominick Grift wrote:
> >>> On Sat, May 06, 2017 at 04:03:58PM +0200, Dominick Grift wrote:
> 
> [snip]
> 
>  
>  Nice! Unfornately i could not, which my limited capacity, get it to 
>  work. Here is what i tried:
>  
>  Fedora 26 (alpha):
>  sudo dnf install setools setools-console libselinux-python3 pandoc which
>  git clone https://github.com/quarcksecurity/span && cd span && pip3 
>  install . --user
>  cd examples && jupyter-notebook
>  
>  As soon as i try to run any "cell" or do "restart kernel and run all 
>  cells" it throws stack traces about "ModuleNotFoundError" (import span 
>  as se" and "from sh import pandoc" 
>  
>  All the stuff seems to be installed properly in 
>  ~/.local/lib/python3.6/site-packages, and the stack traces do refer to 
>  the proper paths suchs as for example: 
>  "/home/joe/.local/lib/python3.6/site-packages/span/domain_summary_to_word.py
>   in  ()"
> >>> 
> >>> I dont know exactly what the issue is but after installing the following 
> >>> from the fedora repository i seem to have it working:
> >>> 
> >>> python3-pypandoc
> >>> python3-pandocfilters
> >>> python3-sh
> >>> 
> >>> So i suspect the "from sh import pandoc" was the issue because sh was not 
> >>> in the python_requirements.txt, but even after adding it there it still 
> >>> did not work
> >> 
> 
> I updated python_requirements.txt to include sh - thanks for that.
> 
> >> 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.
> > 
> > 
> > Turns out that Fedora provides all the dependencies (some just have 
> > different names)
> > 
> > I have created a Fedora SPAN.spec:
> > 
> > https://github.com/DefenSec/selinux-rpm-spec/blob/master/SPAN.spec 
> > 
> > 
> > 
> 
> Thanks for making the Fedora SPEC. 
> 
> I know it’s a topic of great debate, but there are some nice things about 
> just sticking with the Python tools for dependency management for upstream. 
> Mainly because it’s portable and helps get the latest versions (which is nice 
> for fast moving projects like Jupyter notebook and Pandas).

Yes it is pretty cool (pip) and this event actually prompted me to make pip 
work in my environment. However for me in this case it is really not an option. 
Its nice for simple python modules but python programs such as notebook need 
permissions that i do not associate will login users shells, and i dont support 
confining applications installed to $HOME. notebook needs permissions like 
execmem, needs network connectivity and a few other things that i do not allow 
my user login shells. So I have to make this work system-wide and I wanted the 
benefit of being able to manage/keep track off what i install system-wide

> 
> Karl
> 
> 
> >> 
> >>> 
>  
>  -- 
>  Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
>  https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02
>  Dominick Grift
> >>> 
> >>> 
> >>> 
> >>> -- 
> >>> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
> >>> https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02
> >>> Dominick Grift
> >> 
> >> 
> >> 
> >> -- 
> >> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
> >> https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02
> >> Dominick Grift
> > 
> > 
> > 
> > -- 
> > Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
> > https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 
> > 
> > Dominick Grift
> 

-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02
Dominick Grift


signature.asc
Description: PGP signature

Re: Announcing SPAN: SELinux Policy Analysis Notebook

[Karl MacMillan]

> On May 7, 2017, at 5:39 AM, Dominick Grift  wrote:
> 
> On Sat, May 06, 2017 at 07:19:20PM +0200, Dominick Grift wrote:
>> On Sat, May 06, 2017 at 06:19:56PM +0200, Dominick Grift wrote:
>>> On Sat, May 06, 2017 at 04:03:58PM +0200, Dominick Grift wrote:

[snip]

 
 Nice! Unfornately i could not, which my limited capacity, get it to work. 
 Here is what i tried:
 
 Fedora 26 (alpha):
 sudo dnf install setools setools-console libselinux-python3 pandoc which
 git clone https://github.com/quarcksecurity/span && cd span && pip3 
 install . --user
 cd examples && jupyter-notebook
 
 As soon as i try to run any "cell" or do "restart kernel and run all 
 cells" it throws stack traces about "ModuleNotFoundError" (import span as 
 se" and "from sh import pandoc" 
 
 All the stuff seems to be installed properly in 
 ~/.local/lib/python3.6/site-packages, and the stack traces do refer to the 
 proper paths suchs as for example: 
 "/home/joe/.local/lib/python3.6/site-packages/span/domain_summary_to_word.py
  in  ()"
>>> 
>>> I dont know exactly what the issue is but after installing the following 
>>> from the fedora repository i seem to have it working:
>>> 
>>> python3-pypandoc
>>> python3-pandocfilters
>>> python3-sh
>>> 
>>> So i suspect the "from sh import pandoc" was the issue because sh was not 
>>> in the python_requirements.txt, but even after adding it there it still did 
>>> not work
>> 

I updated python_requirements.txt to include sh - thanks for that.

>> 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.
> 
> 
> Turns out that Fedora provides all the dependencies (some just have different 
> names)
> 
> I have created a Fedora SPAN.spec:
> 
> https://github.com/DefenSec/selinux-rpm-spec/blob/master/SPAN.spec 
> 
> 
> 

Thanks for making the Fedora SPEC. 

I know it’s a topic of great debate, but there are some nice things about just 
sticking with the Python tools for dependency management for upstream. Mainly 
because it’s portable and helps get the latest versions (which is nice for fast 
moving projects like Jupyter notebook and Pandas).

Karl


>> 
>>> 
 
 -- 
 Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
 https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02
 Dominick Grift
>>> 
>>> 
>>> 
>>> -- 
>>> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
>>> https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02
>>> Dominick Grift
>> 
>> 
>> 
>> -- 
>> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
>> https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02
>> Dominick Grift
> 
> 
> 
> -- 
> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
> https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 
> 
> Dominick Grift

Re: Why does Python want to read /proc/meminfo

[Stephen Smalley]

On Sat, 2017-05-06 at 11:07 -0500, Ian Pilcher wrote:
> On 05/06/2017 12:51 AM, dieter wrote:
> > Personally, I doubt that you will find a reference.
> > Instead, I assume that the reference comes from the C runtime
> > library.
> > It might hepl optimize memory management to know about "meminfo"
> > details.
> 
> You're right.  Seems that it's glibc's qsort().
> 
> So it seems that any service written in Python (or any other program
> that uses qsort) needs to be given read access to most of /proc or
> deal
> with the (unspecified) consequences of not allowing qsort() to
> determine
> the amount of memory in the system.
> 
> Delightful.

Alternatively, assign a specific type to /proc/meminfo and allow read
to it without opening up access to most of /proc.  That is what Android
has done, for example.

Re: Why does Python want to read /proc/meminfo

[Dan Stromberg]

On Sat, May 6, 2017 at 9:07 AM, Ian Pilcher  wrote:
> On 05/06/2017 12:51 AM, dieter wrote:
> You're right.  Seems that it's glibc's qsort().
>
> So it seems that any service written in Python (or any other program
> that uses qsort) needs to be given read access to most of /proc or deal
> with the (unspecified) consequences of not allowing qsort() to determine
> the amount of memory in the system.

Actually, this appears to be a false conclusion.  Supporting detail
for CPython 2.x and 3.x:

$ strace -f python -c 'import sys' 2>&1 | egrep /proc
below cmd output started 2017 Sat May 06 09:37:36 PM PDT
above cmd output done2017 Sat May 06 09:37:36 PM PDT
dstromberg@dell-inspiron:~ x86_64-unknown-linux-gnu 14674

$ strace -f python3 -c 'import sys' 2>&1 | egrep /proc
below cmd output started 2017 Sat May 06 09:37:53 PM PDT
above cmd output done2017 Sat May 06 09:37:53 PM PDT
dstromberg@dell-inspiron:~ x86_64-unknown-linux-gnu 14674

Also, keep in mind that "python" is just the reference implementation
of the language.  There are several implementations of python the
language now.

Don't be too hard on glibc. It seems to work pretty well, and a good
sort algorithm probably benefits significantly from knowing how much
RAM is available when sorting very large lists.

Also, don't be overly hard on SELinux.  It's a relatively young
technology and may still adapt to such needs better in the future.

HTH

Re: Announcing SPAN: SELinux Policy Analysis Notebook

[Dominick Grift]

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

> 
> -- 
> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
> https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02
> Dominick Grift



-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02
Dominick Grift


signature.asc
Description: PGP signature

Re: Announcing SPAN: SELinux Policy Analysis Notebook

[Dominick Grift]

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

-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02
Dominick Grift


signature.asc
Description: PGP signature