[rsbac] selinux similarites, lack off

[Amon Ott]

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 
protection needs.

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
> SELinux,
> 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
> SELinux
> access vector cache (AVC) or AVC entry references in
> order
> 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
> provides
> extended versions of existing system calls for
> creating new subjects
> and objects with specified labels (execve_secure,
> mkdir_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
> windowing
> 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
> provide
> labeling and separation of individual database records
> maintained
> in a single file.  These application policy enforcers
> would
> still be controlled by the kernel, but could further
> refine
> 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
> process
> 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
> directory
> 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
> controls
> 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 
model coexistence.

- 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 
it.

Amon.
--
http://www.rsbac.org


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?