[devel] FYI: [ao на rsbac.org: [rsbac] Remove LSM support from RSBAC 1.2.3-pre? Issues and musings.]

Ср Окт 15 14:49:25 MSD 2003

----- Forwarded message from Amon Ott <ao на rsbac.org> -----

Date: Mon, 13 Oct 2003 16:37:29 +0200
From: Amon Ott <ao на rsbac.org>
To: RSBAC List <rsbac на rsbac.org>
Subject: [rsbac] Remove LSM support from RSBAC 1.2.3-pre? Issues and musings.
Organization: RSBAC
Reply-To: RSBAC Discussion and Announcements <rsbac на rsbac.org>

Hello again!

After weeks of reflecting, I have almost decided to throw Linux Security 
Modules (LSM) support out of the RSBAC code and return to the original hooks. 
I will try to summarize my arguments and hereby ask you for your comments to 
come to a final decision.

RSBAC has been ported to 2.6.0-test5 (just updated to -test7) as the current 
1.2.3-pre1. The port uses LSM hooks, where available and applicable, and 
RSBAC hooks otherwise. Certainly, I might have misunderstood some code and 
could have argued with the LSM project about all these issues. On the other 
hand, the current RSBAC version would then probably be 1.2.0 or so.

Issue #1 (incompleteness):
The LSM security_ops array for RSBAC contains 32 decision and 5 notification 
entries, some of which are conditional. There are still 95 decision 
(rsbac_adf_request) and 39 notification (rsbac_adf_set_attr) calls left in 
the RSBAC patch. This means that only one quarter of the necessary decision 
hooks are provided by LSM, and even fewer notification hooks.

In order to use only LSM hooks for decision and notification, a real lot 
of additional hooks would have to be argued, written, verified and included 
into the official kernel code. I have neither time nor desire to do this.

Even a big restructering of the RSBAC code would not help to add hooks that 
are plainly missing, e.g. control of network or firewall settings.

Issue #2 (access control only):
LSM is only about additional, restrictive access control. However, the RSBAC 
system provides a lot of additional functionality, e.g. symlink redirection, 
secure_delete, partial Linux DAC disabling. All this has to be patched into 
kernel functions in a separate patch.
One can argue that all this is not essential, and so could be patched in as 
an optional addition. I hold against that it would cripple the whole RSBAC 
system.

Issue #3 (low level internal data structures):
LSM hooks export (expose) kernel internal data structures as parameters, from 
which all LSM modules have to extract their data. This is extremely 
dangerous, because a simple bug (like = instead of ==) can destabilize the 
whole system.

Additionally, kernel internal data structures tend to be changed quite 
frequently between releases - with every new kernel version, one has to check 
whether the items are used correctly and if the correct locks are held. All 
this leads to a mess of #ifdefs for the kernel version, instead of the IMHO 
very important independency of kernel versions.

Issue #4 (stacking):
The LSM design is not able to support more than one single decision module 
registration. Instead, a system of secondary registrations ("stacking") has 
been introduced, which forms a call chain though all modules, until all have 
been called. Each module is responsible to forward the decision requests of 
all(!) hooks to its secondary module, and to combine its own and the 
secondary result to a return value.

With the stacking system, each registered decision module holds all others 
along the chain in its mercy. I am not willing to accept such a dependency on 
other modules. Furthermore, the need to supply forwarding for all hooks makes 
all code more LSM version dependent and unnecessarily complicates the 
decision code.

Issue #5 (Posix capabilities without stacking support):
Once you have enabled LSM, you only get back Posix capabilities by another 
kernel config switch. This is not bad in itself, you can always have it on, 
but the capability implementation does not support LSM stacking - the usually 
fastest decision module will always have to be the last in the chain.
This means that you cannot avoid Issue #4, if you want to have Posix 
capability support.

Issue #6 (no guaranteed decision call):
With RSBAC, every registered decision function is guaranteed to be called for 
every decision, unless an internal error occurs (return value UNDEFINED). 
This is important for logging and, specially, for notification and state 
update.

Those LSM modules I had a closer look at only forward requests, if they 
themselves allowed access. And, again, this is purely a decision of the 
module up in the chain. If it for some reason does not call its secondaries, 
too bad.

Issue #7 (split up code):
Since there will be need for a separate RSBAC patch for a long time to go, 
LSM support splits up the code. This means that it is more difficult to make 
sure that all interceptions are there exactly once, and it makes the code 
significantly less well structured.

Issue #8 (stateless calls):
As all LSM calls are stateless and do not transport additional data, the 
notification functions have to recalculate all decision relevant data, e.g. 
type and id of the object, which my original RSBAC hooks just keep from the 
decision call. Recalculation slows down the system. In worst case, the 
notification function works on different data from that of the decision.

Stateful decision modules require reliable knowledge, whether some system 
call functionality has been fully performed or stopped and reverted, so the 
notification calls may not be included in the decision calls to avoid this 
problem.

Issue #9 (amount of work):
As far as I can see, supporting LSM requires a lot more work than my original 
hooks - despite the official LSM intention to make life easier for all access 
control extensions. Without significant advantages, I cannot see the point 
why I should invest all this extra work.

-----------------------------------------------
A few more personal remarks on recent events:

When in the year 2000 the first common access control framework for all 
important then existing Linux kernel access control extensions was designed, 
people from LIDS, Medusa, SGI and RSBAC, as well as some other people, 
already solved most of these and some other important issues.
Unfortunately, our design did not get the important impetus to prosper and 
died.

The LSM project, lead mostly by different people (who had also been invited 
to our previous discussion), felt itself bound to Linus' order that security 
must not cost anything in performance, focused on single modules and, sorry 
to say that, mostly ignored the work done by the first approach.

The current official kernel includes only one(!) of the most important 
solutions, and, certainly purely accidentially, the current LSM specially 
meets this solution's needs. I do not want to argue about political and 
market(ing) power, paying full-time developers and money, but I think that 
any integrated solution should at least have been called differently, without 
any hints on organizations outside the Linux community. Also, AFAIK, the 
solution now integrated includes US patented security models, which could at 
any time be activated to earn a lot of money after selling the patents.

I believe all this hurts the Linux project and makes it depend even more on 
commercial or political decisions of one single country - it should have been 
a Linux solution after all. In any case, I am going to continue work on RSBAC 
in the way I believe to be right and appropriate. If you think it should be 
different, persuade me and we are back at the previous sentence...

A final note: Some of the issues and musings have already been discussed with 
others on IRC and via mail during the last weeks.

Amon.
-- 
http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22
_______________________________________________
rsbac mailing list
rsbac на rsbac.org
http://www.rsbac.org/mailman/listinfo/rsbac

----- End forwarded message -----