Re: [lin-sec-mod] Re: Direction of the mailing list/effort

magat_private

Hi!

I really hope that this mailing list will not end up being similar to
some standard groups where no one could agree on the standard because
they were primarily after they marketing position. We are on the
free software market, hence we need standards much more and can adhere to
them much more easily.

A levelezőm azt hiszi, hogy Crispin Cowan a következőeket írta:
> Stephen Smalley wrote:
[]
> > 1) Linus said that he wants a truly generic solution.  Now, I could
[]
> > argue that SELinux already provides a truly generic solution - it is
[]
> I think there's confusion due to different meanings of "generic
> solution".  Yes, SELinux separates policy from enforcement, but it does
[]

Please, please calm down. Do your marketing on other forums.

> impose a set of policy models (Type Enforcement, RBAC).  I think Linus'
> view of "generic solution" is much more draconian, where "generic
> solution" includes *no* solution, i.e. kick security to the curb if you
> don't want/need it.

If we use hooks, it is a matter of kernel config option CONFIG_NO_SECURITY_HOOKS,
or CONFIG_NO_SECURITY.

> > But if you want a truly
> > generic solution, it makes more sense to convert the SELinux and/or
> > RSBAC interface to meet Linus' style than to start from scratch and
> > have to re-argue about every hook.
> 
> I'm reasonably sure that this is not what is wanted in a "generic
> solution".  Rather, the generic solution should enable SELinux or
> RSBAC to be employed if desired.

Yes, we need the right set of hooks.  To figure out which is the right set,
a very good way is to start converting all implementations to lkms. After
you all came up with your sets, you should be locked into a room with lotsa
coffe, and released only with the set agreed upon.

As far as I can see, your hardest time will not be about the place of the
hooks, but about the "which hooks, and how many".

I guess that some kernel options like CONFIG_MINIMAL_SECURITY_HOOKS
and CONFIG_SECURITY_HOOKS_LOG would ease the tension a lot.

> However, I have been told that the SELinux people doubt the viability of
> a LKM interface for their package, and I've seen the RSBAC people claim
> in public that they don't believe that LSM is sufficient for their
> needs.  So, I advocate LSM providing the hooks for SELinux and RSBAC if
> and only if they intend to port to it.

This is The Right Way(TM). If any of them would not come out with an LSM 
version, they would soon be found themselves with a below-criticall-mass
user base. And I really don't see the LKM or not LKM problem as serious
as some others. Part is unrelated (the boot problem), and the other parts
will be handled in short time with good engineering practices.

> 
> 
> > 3) Linus also said that he would be willing to accept security IDs
> > into a number of kernel data structures. Security IDs, if you're not
> > familiar, are a policy-independent data type for security labels
> > already used in SELinux.  We already know what data structures need
> > security IDs for SELinux, since it is already implemented.  RSBAC
> > used a different approach (using separate mappings for binding
> > labels to subjects and objects), but they could probably easily
> > generate a list of the data structures they would like to be able
> > to directly tag.
> 
> This is a serious issue.  Should there be an LSM-wide standard for
> security IDs?  Or should LSM security IDs just be opaque blobs, and
> semantics are imposed by the LSM module that is installed?  I have a hard
> time convincing myself that we've seen the last word in security IDs.
> That plus the above stated fact that RSBAC and SELinux uses different
> notions of IDs suggests that we should go with opaque blobs.

Well, there should be a LSM-wide standard for security IDs, and
(provided that the majority of developers won't learn from the
recent Amon Ott - Stephen Smalley match [0:1 IMHO]), the standard
will be about opaque blobs (which have some size impact, but I as
a user willing to pay it for the fact that we have an architecture).

> My main problem with that is that SubDomain is 1/10th the size of

See above.

<very IMHO>
Yes, the Selinux implementation _is_ a good framework itself which
should be able to provide support for a very wide range of MAC implementations.
And do not forget that they have very much manyears and two another
kernels behind. This is a very great experience with a very solid
theoretical background.

Yes, RSBAC and LIDS (I know only RSBAC a little to tell the truth)
are also good frameworks within themselves, with lotsa real-world
experiences, and with the monolithic approach.

Yes, I am sure that those wirex thingies and the other implementations
are also very cool and the new framework should support em all.

Distilling the best of all breads is a non-trivial task, and involves
some compromises from all parties, but very important.

</IMHO>
-- 
GNU GPL: csak tiszta forrásból

_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module