[rsbac] selinux similarites, lack off
Wed, 27 Feb 2002 18:17:02 +0100
On Wednesday, 27. February 2002 15:08, Metrix wrote:
> taken from the selinux mailing list archive:
This is a rather old discussion, based on RSBAC 1.1.2 design. OK, lets warm
it up again.
> However, RSBAC also differs from SELinux in a number
> of ways:
This has been taken from Stephen Smalleys mails, he is the project leader of
Selinux. Certainly, he focused on what he thinks Selinux is better at,
without working out what RSBAC is better at. Citing his statements is
probably not a neutral approach to a comparison.
BTW, that old discussion has been made on both lists, so you can find it in
the old RSBAC archives as well.
> 1) The GFAC does not specifically address the issue of
> atomic policy
> changes, so RSBAC lacks the SELinux support for
> dynamic security
> policies and revocation.
As stated before, I do not believe in constantly changing your policy. As all
policies are checked on every access, changes come into effect at once. If
you turn on read-write support, you effectively get filesystem access rights
revoked (even when passing file descriptors, see below).
What team of security admins is meant to do all the changing in running
systems? Who is going to review all these changes to avoid security holes?
You are certainly not going to let them happen automatically.
> 2) RSBAC does not appear to provide policy-independent
> data types for
> security labels (the security context and security
> identifier in
>From 1.1.2, there are powerful generic persistent lists. There is no problem
in using the object identifiers as descriptors whereever you want, and put in
abstract data of your preferred size.
If you prefer label numbers (like in Selinux), feel free to introduce another
layer with its overhead.
Still, my main question: what do you need policy independent data types for -
the policies are going the make them policy dependent again anyway.
> Flask/SELinux), and it appears to expose
> policy-specific data types in
> its kernel ADF interfaces (through attribute
> parameters), new system
> calls, and on-disk file labels. Furthermore, the
Why not? Security by obscurity?
If you aim at unneccessary data being kept: In 1.2.0, data for all policies
is internally handled independently. Having common access functions (in the
so-called general data structures) makes life a lot more convenient.
Please keep in mind that RSBAC, as opposed to Selinux, is meant to be a
framework to combine several models as necessary and appropiate for your
If you want to add new labels, go ahead and register as many generic lists
with your convenient descriptors and data as necessary.
> kernel ADF depends on
> private kernel data structures and data types, and
> even takes pointers to
> private kernel objects as parameters through an
> attribute structure for
> some decisions. This weakens the separation between
> policy and
> enforcement. SELinux provides cleaner separation
Yes, there are pointers, but no, they are not used for decision, except the
real user and process ids from current. The dentry and sb pointers are only
used for inheritance - unlike Selinux, RSBAC models often use excessive
inheritance schemes to make administration much easier.
The inheritance itself is encapsulated in the get_parent() function, which is
currently the only one, except Malware scanning in files, to use the
pointers. Everything else uses the target ids like an opaque type.
Feel free to mask them through an extra layer of handles for your own models.
Just think of a whole directory tree having the same role model type, and you
want to change that. Do you want to traverse all the tree on every change?
How do you keep that consistent on a crash?
> between the policy and
> enforcement through its data types, interfaces, and
> even in its
> security server implementation. In part, this cleaner
> separation is a
> historical consequence of the fact that the security
> server was
> originally a user space server running on a
> microkernel in the
> predecessors of SELinux (DTMach, DTOS, and Flask). In
> the security server is a kernel subsystem, like the
> RSBAC ADF,
> but the interface still provides the same separation
> as in its
> predecessor systems.
In RSBAC, the ADF interface is designed to give a good abstraction and make
model implementation easy. For my purposes, the separation is as strong as
desired and needed. Without having a closer look at Selinux than before, I
cannot see that it is so much cleaner.
> 3) RSBAC does not appear to have an equivalent to the
> access vector cache (AVC) or AVC entry references in
> to minimize the performance overhead of its controls.
Unfortunately, I have not yet looked through Selinux performance tests. What
I did see is that RSBAC has little enough overhead to better avoid the
complexity of decision caching, but rather to give the modules full control
over the decision processes.
Again, RSBAC usually runs with a combination of models. I am interested in
all results of all modules, but I would not keep all of them in memory -
there are way too many possible combinations.
Please keep in mind that several modules are state dependent - I would have
to invalidate parts or all of the cache with every state change, or keep all
states as part of the cache descriptor. I am sure not going to do that.
> 4) RSBAC appears to lack equivalents for the extended
> API calls and new
> API calls of SELinux, instead only providing calls for
> setting and getting
> attributes of existing subjects and objects. SELinux
> extended versions of existing system calls for
> creating new subjects
> and objects with specified labels (execve_secure,
RSBAC models instead are specially designed to *avoid* incompatible system
calls and binaries. I see this as an important advantage over Selinux. Just
think of the horrible mess of program versions to support.
However, in such cases where appropiate, there actually are additional system
calls for these purposes, e.g. look at pm_create. I just try to avoid them
through better design.
If you have a closer look inside RC model, you will see that the types of new
objects are mandatorily derived from the current role. Subjects are not meant
to pick their own desired types anyway. That would be discretionary crap.
> It also provides new API calls to allow applications
> to obtain
> security policy decisions from the security server in
> order to
> support application policy enforcers. For example, a
> system might be enhanced to provide labeling and
> separation of
> windows, with controlled cut-and-paste between
> windows, or
> a database management system might be enhanced to
> labeling and separation of individual database records
> in a single file. These application policy enforcers
> still be controlled by the kernel, but could further
> the granularity of protection provided by the kernel.
I could write you an RSBAC REG interface kernel module which provides you
such an interface within a few days. You already know that in RSBAC you can
combine as many modules as you want. Still, so far nobody ever showed any
interest in getting such an RSBAC interface.
The idea itself has already been presented in our NordSec 1998 paper about
Malware Scanning Approaches and as such is far from new to me. I am pretty
sure that others had the same idea much longer ago.
Further more, this would again place access control enforcement back into
user mode programs. RSBAC fundamentally tries to limit the user space
problems you are trying to reintroduce here.
Personally, I do not believe in user space providing any good security.
> 5) RSBAC appears to lack a number of the controls
> provided by SELinux for
> each of the kernel subsystems. Some examples of such
> gaps in its
> controls include: consistent controls on changes in
> labels, controls on the inheritance and transfer of
> open file
> descriptions across execve or via local IPC, control
> of asynchronous I/O
> signals, control of receiving the exit status via
> wait, controls on
> the use of Linux capabilities, failure to check
> permission to
> all affected directories and files for several of the
> operations, and the lack of an equivalent to the
> layered networking
> controls provided by SELinux. Furthermore, the
> SELinux controls are
> designed to address both the case where the ordinary
> API call is used
> (e.g. execve) and the case where the extended API call
> is used (e.g.
> execve_secure) in a consistent manner, while the RSBAC
> only address the ordinary API calls.
As explained above, the 'extended APIs' are something I am trying to avoid,
so that point does not hold here.
Which directory operations did I miss, except those that are not relevant for
my decision modules?
RSBAC network access control has just been completely redesigned. I believe
that the new scheme solves such problems as I personally see on server
systems in a consistent and flexible way.
In RSBAC, IPC has been controlled for a longer time than Selinux existed even
in a first test version. If processes want to pass file descriptors to others
they are welcome to do so - I just do not guarantee that they will be of any
use later on, if there is no sufficient access right for READ and WRITE.
> 7) Most of the RSBAC policy modules are very hardwired
> in their
> policy logic, and can be easily expressed using the
> SELinux Type
> Enforcement (TE) configuration. The RSBAC Role
This false statement has been made before, and I am beginning to get a bit
tired of explaining all these items again and again. When Stephen first
claimed this, he had to take back most of it.
As one example, he could not express the important separation of
administration duty of my main models (RC and ACL). Even the simple
combination of RC, AUTH and FF would result in a very complicated setup.
The term 'easy' does not even hold for MAC (Bell-LaPadula) - this is why the
Selinux team provided an extra module for it...
[detailed description of Selinux single oversized model and a comparision to
only one of my models cut out]
You do not seem to get my point with the provided models:
- Each single model on a system must have a limited scope and complexity, so
it is easy to understand and use properly.
I am no expert in the Selinux role model, but all I heard makes me believe it
is very difficult to keep the overview of its administration, specially with
the constant changes they are eager to make.
- Each single model must be able to be applied to only part of the system.
I have no idea how Selinux would solve this, because it is not meant for
- No model should interfere with others, except where providing additional
functionality (e.g. RC roles in ACL).
This point and the previous one let you break down administration into
smaller parts, which are much easier to understand and maintain. Does Selinux
have such a concept?
- There must be different models for different needs. E.g., there are tasks
that can only very badly be solved with role models.
With RSBAC, just choose you appropiate model for each part of the system, and
make it a powerful combination. With Selinux, you have to try to emulate
other model approaches or modify your needs to fit the model.
Let the Selinux people go ahead with their one-size-fits-all-model mentality
and be happy.
I just do not want to use an oversized tent maze with configurable labels as
a T-Shirt, additionally without being able to change size, color or shape of
P.S.: On Linux Kongress, somebody presented me a new model which could
probably really express the Selinux model together with all my RSBAC models
(except Malware scan... :). Administration was meant to be done through a
three dimensional graphical interface.
My main question was: Who is going to understand and apply such a model
without gasping security holes?