Hi folks,
this is a late reply, because I was away for a week.
On Dienstag 15 Februar 2005 23:38, Lorenzo Hernández García-Hierro
wrote:
> The purpose of this email is not re-opening the old flame on the
> anti-LSM "pleas" that were subject of many discussion and
> disappointments in certain developers and user groups.
>
> I will try to answer some of those in as much as possible organized
> manner, without any personal opinion being show in front of the
> objective analysis, and talking from the side of the developer who
is
> looking at the advantages and shortcomings of different solutions to
> achieve almost the same thing (or at least, help when achieving it):
>
> [ http://www.rsbac.org/documentation/lsm.php ]
This is my text, written some time ago. Some of the arguments are
still valid, some others have been discussed in the mean time.
> -> 1. Incompleteness
>
> AFAIK, the LSM framework has evolved much more since it got accepted
in
> the kernel mainline, many independent hackers contributed to it
because
> they thought that it needed further improvement, but even if people
> could think in the beginning that it was going to be more a weakness
> than a real security enhancement, nowadays there are many available
> hooks, demonstrating how complete it can be, also, hooks can be
added
I have no doubt that many small improvements have been done, and LSM
is more complete by now. My main objectives are still valid, though.
> easily even if there's no (AFAIK, visible) documentation on it (a
thing
> I'm planning to solve in the forthcoming months, maybe updating the
> current documentation at immunix.org), depending on how well the
> developer knows about how LSM framework works and how the kernel DAC
and
> standard checks work themselves.
Documentation is a general problem in all projects, not only the
kernel. For me, this has never been an issue against LSM, although
some things, especially the weird stacking, should be documented to
avoid errors in implementation.
> The point is that people must have in mind that hooks need to work
as
> they are supposed to do: no ABI/API breaking, no unexpected effects
on
> "normal operation flow" of the kernel (if it's not explicitly
wanted),
> no extra overhead or logics messing...etc.
Agreed to "not breaking APIs", unless unavoidable to get some
important functionality. And certainly, all extensions must be
optional.
I strongly object against the "no overhead" argument, as I did many
times before. Overhead should be low, and it can be. Security comes
with some costs - you can either say "minimize overhead at all
costs", "maximize security at all costs", or try to make a good
balance. IMHO, the first has been selected as a guide for LSM to get
it accepted for mainline, which I still regard as a bad decision.
As pointed out in another reply, the actual real world overhead is
pretty small - even with more extensive and data gathering hooks like
those of RSBAC. Even making MAC decisions with logging checks before
the Linux DAC decisions should be acceptable, because in almost all
cases access will be granted anyway, so the order of calls does not
matter.
> In addition, LKMs using the LSM framework *don't need* to use *only*
a
> procfs sysctl interface or something alike for providing
> user-land<->kernel space communication capabilities.
> We have more options: registering a sysfs-based subsystem for
example.
This is a portability issue, these interfaces are very Linux specific,
some are even kernel version specific. The good old syscall is very
portable, and you can use a dispatcher to march dozens of calls
through this.
> -> 2. Access Control Only
>
> Yes, and that's noticed from the "official" documentation.
> But, who says that we can't place auditing facilities inside the
> existing hooks? or even file system linking related tweaks?
There is a separate auditing subsystem now, but this was not my point.
Access decisions can be logged where they happen, or in some central
dispatcher.
> Also, why disabling DAC? It's not a good idea if you have to handle
> *ALL* at *your OWN*.
> And it represents, BTW, a real performance hit because you do
*double
> checking* or logics overhead.
Some people even want to override DAC, because it is quite limited. I
agree that this is dangerous - overriding should be off by default,
and there must be a big warning.
Actually, in RSBAC you have separate decisions for every active
decision module - up to 13 decisions for each request, plus the
runtime loaded modules registered through the REG facility. This is
not a problem, if it gives you a real benefit. My usual configuration
has 7 modules active, and the overhead is still low.
> DAC checks normally *override* LSM checks, except in certain
situations
> when both pre- and post-processing LSM hooks are used.
No, they do not override LSM checks - they cannot grant access, if LSM
wants to deny it.
> An operation must at least be (if no override present): 1) DAC
> compliant, 2) LSM->user compliant.
>
> Going into personal thoughts, what's the point of having a *real
pain*
> and maintenance overhead due to modifying the by-default permissions
and
> access control basis with your own, even if they can live and have
sex
> together?
There are cases where Linux DAC and MAC cannot live happily together,
because Linux DAC is too limited.
If you look at the SELinux default policy, you will see that they try
to do everything with SELinux, because only MAC settings are trusted.
Well, sure, this is painful, but can be necessary in some cases.
In RSBAC, you can convert Linux DAC settings to ACLs before switching
DAC off for some directory tree. This gives you complete DAC
settings, but makes them more flexible, fine grained and more MAC
like than standard Linux, because administration is no longer "owner"
based.
> -> 3. Low Level Internal Data Structures
>
> I agree that incorrect handling of the structures on-flow can lead
to
> kernel stack or runtime corruption, but this is nonsense to be
claimed
> as an LSM fault.
Again, I disagree. If you look at the age old discussion RSBAC vs.
SELinux between Stephen Smalley and me, he criticized that even the
few structures available in RSBAC hooks were dangerous.
Now LSM exposes many, many more of them, and expects modules to use
them directly. Most RSBAC modules work without ever touching the few
structures.
> I had freezes many times when I started doing some development with
the
> LSM framework, but it was more because of my incompetency than the
> framework itself.
It is easy to freeze the kernel, but it is much easier, if you must
access lots of structures under locking conditions you do not know
about (and which might change between kernel versions).
> When new kernel releases hit the streets, LSM framework is stable
and
> compatible with it, as many people contributes and also the folks
> maintaining it are good and responsible ones.
It is stable for what it does - most of my points are against design,
not implementation.
> -> 4. Stacking
>
> I agree with this, but AFAIK there has been work done in this area,
as
> far it comes to mind, Serge Hallyn is someone to be asked about it.
The stacking problem is a direct consequence of the design with
distributed single user hooks. It has been criticized from the very
beginning and since then people have been trying to solve it.
Another big problem is that there is only one pointer at some kernel
structures for attribute data - which module is allowed to use this?
The first? Any? How do you know whether it is used or not?
> -> 5. Posix Capabilities Without Stacking Support
>
> I don't get the point of these claims.
> The LSM framework currently has full support for dynamic and
> logic-changeable POSIX.1e capabilities, using the capable() hook and
> calling capable(from whatever location inside any other hook to
apply
> further logic checks (ie. in capable() check for jailed @current
process
> and deny use of CAP_SYS_CHROOT and CAP_SYS_ADMIN or what-ever-else
> capabilities) or in syslog() to deny access to kernel messages stack
to
> unprivileged users.
Without rechecking the current state: At least the last time I
checked, the hardwired kernel capabilities were explicitely disabled
when LSM got switched on. You had to use the capabilities LSM module
instead, which was not able to stack. It always had to be the last in
the chain, thus effectively sealing against any other LSM module to
be loaded later.
Make a short google search for LSM and capabilities, and you will find
loads of user problem reports for this topic. Again, this is only a
consequence of previous design decisions for the hooks, although a
complete implementation of the capability module would have avoided
the problem to show.
> -> 6. No Guaranteed Decision Call
>
> LSM hook architecture is designed (at least on current 2.6 brand) to
> return the decision calls results only if they have been
successfully
> defined and initialized (ie. typical if (ret) { return ret; } ).
You completely missed my point: The first LSM module decides, whether
to call all the others or not, and so on through the chain. Most LSM
modules do not call the others, if they want to deny access
themselves.
This works fine with stateless security models, but it gives you a
hell of a pain for a stateful model - or with non-access control
modules, e.g. for virus scanners, which always want to check even for
denied accesses.
> -> 7. Split Up Code
>
> That's just a personal remark, and, at least for me, the framework
looks
> pretty well structured and code seems as well distributed and
organized
> In The Right Way (tm).
Well, this "personal" and the other problems happen to make LSM
unusable for RSBAC, GRSecurity and others.
The split code argument has another, severe variant:
As all hooks stand independent beside each other and there is no
central decision function, you can never be sure that your LSM module
catches all relevant events in a given kernel version - unless you
inspect every kernel version and either add lots of #ifdefs, or
restrict your module to one single kernel version.
The problem is getting worse (again) with stacking - you can never be
sure, that you pass all relevant events to the modules registered
after yours.
The concept behind the central function is the "reference monitor", a
central component, which is guaranteed to get requests for all
accesses to make access control decisions.
> It's a good point that even a child can understand it and do
something
> out of it too (I couldn't avoid to make this one).
Sorry, but unfortunately, security is usually more complex than what
most children can comprehend. A simple interface does not
automatically make its usage simple. The side effects with locking
and races can be severe.
> -> 8. Stateless Calls
>
> As shown above, the hooks get as arguments all the necessary data to
> handle the operation and do anything on it to return the "right"
result
> depending on the followed logic.
>
> Most calls that make use of properties transition such as id's
changing
> ones (ie. old_suid -> new_suid) are handled with both values.
>
> In short, most time you don't need and *shouldn't* initialize
structures
> or whatever else, as you may have them available globally, or at
least
> passed as arguments from the original call to hook in the origin
> syscall.
Again, this was not my point. For decisions in most real security
models, you need some metadata. You can gather this in the hooks, and
thus avoid direct kernel data structure access, or gather it in the
decision logic. If you do the latter, you have to redo the gathering
in the post call - with possibly different results because of
parallel processes.
> -> 9. Amount of Work
>
> Again it's a personal remark, not objective.
> At least from my point of view, I've needed less time to achieve the
> same goal by using the LSM framework.
What where your goals? Did you have a complete, more extensive
infrastructure, which you had to change to LSM? What models did you
implement?
Similar remarks, but the other way round, have been made for the RSBAC
REG facility. It is also a matter of what you know better and how you
work.
> Indeed, at least in 2.6 brand, if you know how to handle it and how
> things work or even change between releases, the maintenance
overhead is
> *minimal*.
Let me express it this way: I am pretty sure that the implementation
of a given security model is much smaller, less error prone, easier
to port to new kernel versions and probably even significantly faster
without further optimization, if you use the existing RSBAC
infrastructure, than when using LSM hooks.
There are some examples of small LSM modules, which have been quickly
ported to RSBAC and now live in the rsbac/adf/reg subdir as examples
for runtime registration. As they do no longer need to implement
stacking, the code became very small.
> -> Final Remarks <-
>
> My thoughts on the personal remarks shown at
> http://www.rsbac.org/documentation/lsm.php are pretty short ones:
>
> Immunix, which seems to be the subject of the political,
> marketing-related comments has no hand-over-overall-project, and
they
> failed in most of the things they tried to do, at least from the
public
> eye such as supporting proprietary modules to do stacking, inode id
> structures tweaks and such.
Your guess is wrong, I was hinting more at SELinux than at Immunix
here. My statements were political, because many decisions look very
political. And, as explicitely written, they presented my personal
impressions on the whole process.
> Think that they investors may dislike the model they followed when
the
> merge happened, anyways, and as an example, I pretty ignore those
> patents claims,for example, think that Type Enforcement (TE) is
patented
> and before SELinux got in mainline the enterprise with rights on the
> patent made a public announcement about their "opening" and
"for-free"
> use of their patented model.
When this happened, it seemed clear, that after selling the patents
anything could happen. Think of SCO and how they hindered Linux, and
then rethink what problems might appear with clearly accepted patents
all over the business and in various distributions.
Well, I am sure most people here agree that software patents are bad
for free software, so let's not dig into this.
> I'm not a lawyer, but if they protest to get that rights back and
put
> price in our holy heads, they will get in trouble, with investors
and
> both users and developers.Nobody likes to listen to lies, and if
they
> did a one, then too much people will be disappointed with them.
> I don't think they will do anything like that if they haven't
already
> done it ;).
Companies are there to make money, not to provide public benefits.
Sad, but true.
> As a little disclaimer, just to say that I'm pretty new here so,
maybe
> I'm not the best one recall on this, but at least I'm making use of
my
> rights to comment on it.
I appreciate you continued struggle against us thick headed developers
to get a better common solution. Still, some problems are deeper than
they appear, and you will often have politics or even massive company
interests involved.
Amon.
--
http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22
This archive was generated by hypermail 2.1.3 : Tue Feb 22 2005 - 07:35:04 PST