[rsbac] Network controls

[shahbaz khan]

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.

> 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?

> 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

If the above questions can be answered from the book do not worry
about the above questions.

> > 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?

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

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?

Have you considered something similar to AVC of selinux for rsbac? 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.

Shaz.

> http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22
> _______________________________________________
> rsbac mailing list
> rsbac at rsbac.org
> http://www.rsbac.org/mailman/listinfo/rsbac
>