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?
2. return self.find_def("attribute " + name) # in CIL this is typeattribute
3. return self.grep(type_name, "*.fc", self.modules_path) # CIL has its context
specs in the .cil suffixed file
4.
return self.diff_relative("/policy/mls", other_source) # these should be
customizable
return self.diff_relative("/policy/mcs", other_source) # these should be
customizable
return self.diff_relative("/policy/constraints", other_source) # these should
be customizable
5. any references to type attributes should be customizable: ie. process_types
= ... filesystem_types = ... etc
>
> 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
signature.asc
Description: PGP signature
