[rsbac] Network controls

[Amon Ott]

On Wednesday 01 August 2007 12:22, shahbaz khan wrote:
> On 8/1/07, Amon Ott <ao at rsbac.org> wrote:
> > On Monday 30 July 2007 22:19, shahbaz khan wrote:
> > > I will appreciate som details or references anout the
> > > implementation of network controls of rsbac w.r.t.
> > > implementaion usability and functionality.
> >
> > RSBAC network access control works on the logical connection
> > level (OSI transport level, level 4). It defines local and remote
> > endpoints by network family, connection type, address, port, etc.
> > Then all network accesses are controlled by requests like CREATE,
> > BIND, CONNECT, SEND, RECEIVE, etc.
> >
> > All accesses involving network transfers are checked with the
> > remote endpoint as object, all others with the local endpoint.
> > This means that you can e.g. control BIND to certain local ports
> > as well as CONNECT to or ACCEPT from a certain remote address and
> > port.
>
> Please shed some light on remote endpoint object.

This is the remote end of one step in communication, e.g. a TCP port 
on another system. Anything reachable over the network.

> > As network endpoints are usually very short lived, attribute
> > defaults for them are assigned through Network Templates. They
> > are ordered by numbers and describe a set of endpoints. The
> > matching template with the lowest number provides the attribute
> > values, e.g. the RC type or the ACL.
>
> I did not get the numbers in here. How and why are they assigned.
> What do they represent? How is the matching facilitated?

The numbers are given by the admin creating the template. Each 
template has a unique number. The endpoint matching function walks 
though the list of templates from lowest to highest number and picks 
the first template that matches.

> > > I will also like if anybody can explain how syscall
> > > interception in rsbac works from
> > > the implementors perspective. Is this equivalent to LSM. Does
> > > rsbac has any dependability on LSM?
> >
> > RSBAC intercepts at similar (and more) places as LSM, but it does
> > not use LSM. Major differences are that RSBAC interceptions use
> > an abstraction into request types and that it tries not to change
> > any existing kernel structures.
>
> How is this abstraction implemented? Is it similar to LSM
> abstraction?

Instead of calling a separate LSM function everywhere, which has to be 
implemented by all LSM modules, RSBAC has one single decision 
function. The request type is one parameter to this function.

RSBAC does not have a one-to-one matching between system call and 
request type, but a logical connection to the functionality. E.g. 
sys_open can lead to READ_OPEN, WRITE_OPEN, READ_WRITE_OPEN, 
APPEND_OPEN, DELETE and CREATE, depending on what it really does. 
OTOH, sys_*stat are all mapped to GET_STATUS_DATA. One system call 
can require several requests to be allowed.

> Can we bring the ipsec associations to rsbac? I think it will also
> be feasible to carry attributes in rpc headers for a more
> distributed implementation. Has any work being done on this?

There has been a high level design for a clustered RSBAC system, but 
this does not entrust attributes to IPSEC. So you can say that no 
such work has been started.

> Have you considered something similar to AVC of selinux for rsbac?

RSBAC guarantees that every decision module gets called for every 
request, so that they can update their state accordingly and possibly 
decide differently when the same request happens again. This means 
that decisions must not be cached. In other words: Yes, we 
considered, but we decided against it.

A big difference between SELinux and RSBAC is that RSBAC is mostly a 
framework, which allows to implement almost any kind of security 
model with minimal effort and already includes a variety of them. It 
must take great care not to restrict the modules. It also allows to 
run several models in parallel, and no model may influence another 
one, unless explicitely designed to do so.

What we have is the FD cache. It caches attribute values for 
filesystem objects, so that they do not need to be recalculated. The 
reason for this is another difference: RSBAC uses attribute 
inheritance whereever possible (also called implicit labelling) to 
minimize overhead for attribute storage, while SELinux has a separate 
(explicit) label at every object.

> Its a nice feature to reduce overheads. Have you done something for
> security aware applications? I mean any extended api for setting
> and getting attributes. This would enable multiple AEF reducing
> load on kernel subsystems and at the same time spread security
> mechanisms to most of the system.

There is the RSBAC library librsbac.so, which allows to get and set 
attributes from userland - if you have sufficient rights to do so. 
E.g. the RC model allows to actively change the current role, if 
allowed by administration ("compatible role").

The optional REG API allows to register more decision modules at 
runtime, e.g. from a kernel module. And the generic list 
implementation allows to store most kinds of single or double level 
lists persistently, including support for transactions.

Yet another difference: All RSBAC administration is access controlled 
by all modules it affects. There is no complete policy block to be 
loaded by one single admin, instead every single attribute has to be 
set separately under full access control of the modules. Some modules 
have schemes for separation of administration duty, specially RC and 
ACL. These schemes would be impossible without the detailed control.

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