Re: AVC in RSBAC

From: Amon Ott <ao@rsbac.org>
Subject: Re: AVC in RSBAC
Date: Wed, 18 Apr 2001 14:32:39 +0200

Next Article (by Date): Re: Re[10]: RSBAC v1.1.1 problem Amon Ott
Previous Article (by Date): Re: New setreuid() and setresuid() logic Stanislav Ievlev
Top of Thread: AVC in RSBAC Stanislav Ievlev
Articles sorted by: [Date] [Author] [Subject]

On Die, 17 Apr 2001 Stanislav Ievlev wrote:
> I've just closely read discussion SELinux vs. RSBAC. There is very 
> interesting idea about cache for decisions. It's not so difficult to add 
> this cache into RSBAC architecture.
> 
> 1. Main decision function can see result in cache first and then call 
> other decision funcions if cannot to find result.
> 2. Funcion that change some attribute must clear corresponding value in 
> cache.

I also thought about that. Still, the cache would have to be rather large. We
would have to store:

Keys:
- All request params

Data:
- All single module decisions (for logging)

The cache would have to be organized with several hashes so that access is fast
and invalidation is only performed for small parts of the cache.

Invalidation could be done for single modules only.

Also, there are some problems:
- The set_attr function calls are still needed
- Some models quite often change attributes, e.g. MAC with current_level. This
would mean lots of invalidations for MAC.

This might be a good stress test for the new generic lists...

Another point: The SMP benchmark showed little module call overhead. Are the
cache overhead and complexity worthwhile?

Amon.
-
To unsubscribe from the rsbac list, send a mail to
majordomo@rsbac.org with
unsubscribe rsbac
as single line in the body.

Go to Compuniverse LWGate Home Page.