[rsbac] Decision Module in Userspace

Amon Ott ao at rsbac.org
Tue Jun 7 12:40:28 CEST 2011

On Sunday 05 June 2011 wrote Shaz:
> On Sun, Jun 5, 2011 at 8:31 PM, Shaz <shazalive at gmail.com> wrote:
> > On Sun, Jun 5, 2011 at 8:12 PM, Jens Kasten <igraltist at rsbac.org> wrote:
> >> Hi,
> >>
> >> a point to your Django framework.
> >> Why should not use RSBAC to secure the webframe work?
> >> So far I understand, I would not need for daily use and additional
> >> module in userspace.
> >> I would analyse what files and directories are directly affected by the,
> >> if Django runs under his own user, and start to build RC-Roles and
> >> RC-Types. Than a Nettemplate and other small thinks.
> >> Now, why I should build RC-Roles befor, so that a userspace software get
> >> again a RC-Role to obtain his limitation?
> >> When I would lift up the decision to userspace, so that a software can
> >> ask if the subject has the correct rights to the object the data have to
> >> protect by what? If data must store again in the main place, rsbac.dat
> >> in every mountpoint, so no reason to build more software to lift up the
> >> decision to userspace.
> >
> > What if we are thinking inside Django and the objects of Django not
> > looking at Django from outside. Not the resources at the kernel/os point
> > of view.
> >
> > Another example would be the elements of Django in the file and not just
> > the file. Granularity with respect to Django.
> Subject and objects at kernel layer is definitely controlled by rsbac. Then
> we have subjects and objects of applications run on frameworks like Django,
> Java and Python. Is it a good idea to use or extend rsbac at the
> application layer? Or do we just simply stack the access control at both
> layers.
> This seems easy with respect to DAC but when we move to something like MAC
> (RC model) this gets confusing. The confusion can be further magnified when
> information flows or object distribution from application context through
> kernel/system context to another application context. Some sort of
> administration would be required to manage cross context attributes of
> subjects and objects.
> I hope this is making sense.

In general for RSBAC, everything that is security relevant for the whole 
system must be inside the kernel if ever possible. This has been an important 
design decision.

The only necessary exception so far has been with DAZ module and on-access 
scanning. The scanners are too dangerous to run in the kernel, but RSBAC 
decides what is to be scanned and what to do with the scanner results. 
Addtionally, all accesses by the scanner are fully access controlled.

In my opinion, there are two things that could be moved into user space:
1. decision modules
2. subject and object labelling (when not identifyable by kernel)

1. I believe that decision modules should not be in user space, because user 
space can be tampered with and thus endanger the whole access control system 
that relies on them. Addionally, I had the opportunity to follow the Medusa 
DS9 project, which had severe performance and stability problems with that 
approach, mostly caused by context switches and deadlocks on resources. My 
own benchmarks with DAZ result caching also showed that context switch 
penalty is huge.
This said, you can of course quite easily write a REG kernel module as an 
interface to a user space decision daemon.

2. User space programs could ask RSBAC decision modules for decisions 
like "RC: may role n access FD type m?" and act accordingly. E.g. dbus could 
put labels on its connections and enforce the decisions coming down from 
kernel. However, this means that dbus must be trusted completely for access 
My preferred approach is to control the IPC flow between dbus and other 
processes from outside at kernel level. Then, we could try to have additional 
control inside dbus over information flow betreen certain dbus clients. 
Always try to have more than one layer of control.

http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22

More information about the rsbac mailing list