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 <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 = [ "", "", "", ... ]As a matter of fact, constraints could be anywhere. So probably better to find a different way to get all the constraints in cil you can have your constraints whereever you want. For example : I have my dbus constraints in dbus.cil with the other dbus policy This is not unique. This is how it should be with CIL or any high level policy on top of CIL it was a limitation of module policy that we couldnt have constraints in modules in the past > > 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 -- 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
