[rsbac] Thoughts on the "No Linux Security Modules framework" old claims

[Amon Ott]

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
-------------- nächster Teil --------------
Ein Dateianhang mit Bin?rdaten wurde geschreddert...
Dateiname   : nicht verf?gbar
Dateityp    : application/pgp-signature
Dateigr??e  : 189 bytes
Beschreibung: nicht verf?gbar
URL         : http://www.rsbac.org/pipermail/rsbac/attachments/20050221/a287b7a3/attachment-0001.bin