[rsbac] Network controls

[Amon Ott]

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.

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.

Network Templates are separate objects, access controlled as NETTEMP 
targets. So each decision module can decide per template, whether 
some access (CREATE, READ, WRITE, ...) is allowed for a certain 
process.

You can find more info about templates at 
http://www.rsbac.org/documentation/administration_examples/network_access_control

The concepts behind are described in detail in the RSBAC book, see 
http://www.rsbac.org/documentation

> 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. This makes RSBAC easily compatible 
between different kernel versions, e.g. you can boot 2.4 and 2.6 
kernels with the same RSBAC version and it always works the same way.

http://www.rsbac.org/documentation/why_rsbac_does_not_use_lsm explains 
my decision _not_ to use LSM. In my opinion, LSM has been broken by 
design from the very beginning. 

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