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 <dac.overr...@gmail.com> 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?
We should make this customizable something like: source_policy_suffix =
Because we would need to catch *.conf , *.te , *.cil and any future high level
source policy files that leverage cil
> 2. return self.find_def("attribute " + name) # in CIL this is typeattribute
CIL is a native language so we use a statement for something then we need to
make sure that also its CIL equivalent is caught
> 3. return self.grep(type_name, "*.fc", self.modules_path) # CIL has its
> context specs in the .cil suffixed file
We should make this customizable: file_contexts_suffix =
to catch *.fc as well as *.cil and any future high level file_context suffixes
When this suffix is used we should also alway take "file_contexts" into account
as this is where to look in monolitic policy
> 4.
> return self.diff_relative("/policy/mls", other_source) # these should be
> customizable
mls_constraints =
> return self.diff_relative("/policy/mcs", other_source) # these should be
> customizable
mcs_constraints =
> return self.diff_relative("/policy/constraints", other_source) # these should
> be customizable
constraints =
or maybe dont even differentiate between the various different constraints and
just pile them all together in:
constraints = [ "", "", "", ... ]
This is because there may be other constraints (for example i have role-base
access control seperation constraints)
> 5. any references to type attributes should be customizable: ie.
> process_types = ... filesystem_types = ... etc
I do not consider Linux access vectors to be customizable, unlike types
,attributes, booleans, tunables etc)
So one does not have to worry about the hard coding of classes and permission,
However i would probably still try to find a way
make that more easily customizable. Because new permissions get added to
existing classes and if you have you access vector declarations in a single
place then that is easier to maintain then when you have to add then in code
scathered accross the project
>
> >
> > 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&search=0x3B6C5F1D2C7B6B02
> > >>>> <https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02>
> > >>>>
> > >>>> <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>
> > >>>
> > >>> <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
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
signature.asc
Description: PGP signature
