[rsbac] secure code

Jörgen Sigvardsson rsbac@rsbac.org
Tue Aug 13 11:13:01 2002

> If there was no issue with exploitable software, and all code was
> (in the sense without vulnerabilities), perhaps using an alternative
> computer language, would there still be a need for RBAC? What do you
> think?

All applications are subject to security policies. A program may very
well be bug free and non-exploitable given a certain state of its
environment. But when the environment changes, the application may do
things that isn't allowed according to the security policy. There was no
security breach in the application, but in the environment. 

Consider the command rm for instance. rm /tmp/* may be perfectly valid
according to the security policy. But rm /dev/* (or rm -rf /) is most
likely not! The change that made the security breach was in the
environment (command line) and not in the application itself. One could
imagine that the command rm would check what its deleting by itself -
but this would be counter productive - you'd have to update rm everytime
the file system changes according. And it also violates the UNIX
principle that the OS should provide mechanisms - NOT policies. You can
easily figure out that the system would become very complex - not good
from a administration point of view. Also, you'd loose the flexibility.

I can imagine that a very specialized secure system could take on this
approach, but operating systems today are not geared towards a single
solution. It's supposed to handle all kinds of problems.

A better solution is therefore to use a "third party software module"
which mediates requests between the kernel and the application. This
module can then deny or accept requests (such as unlinking file inodes)
based on user/role, application and application environment state (and
kernel state if you wish). RSBAC gives you the mechanism to do this kind
of requests. The policies are then implemented in separate modules
combined with rules set up by the security administrator.

So, to answer your question; Yes, there would still be a need for RSBAC
if you still want that flexible system which you can use to solve a wide
variety of problems.

// Jörgen Sigvardsson