From: Amon Ott <ao@rsbac.org>
Subject: Re: Understanding ACI
Date: Mon, 19 Feb 2001 18:13:56 +0100
Next Article (by Author): Re: REG changes Amon Ott
Previous Article (by Author): REG changes Amon Ott
Top of Thread: Understanding ACI Jörgen Sigvardsson
Next in Thread: Re: Understanding ACI Jörgen Sigvardsson
Articles sorted by: [Date]
[Author]
[Subject]
On Mon, 19 Feb 2001 Jörgen Sigvardsson wrote:
> This is what I have gathered from various source files so far:
> * The ACI-manages security attributes for various OS objects (files, IPC
> objects, etc)
> * These attributes can be accessed through rsbac_{get,set}_attr() functions
> * ACI is a collection of databases (lists) for various kinds of OS objects,
> but this hidden from the user (adf module)
> * Each entry in the DB (fd, ipc or whatever) is defined by the structures
> found in aci_data_structures.h
> * Each entry is static in size, it may only vary in size depending on version
> (current, old, and oldold :)
> * Some entries are persistent (i.e ACL attributes for instance), while some
> are not (i.e. process attributes)
Right: General attributes, as implemented in aci_data_structures.[hc], are for
static size values.
> What I want to do is:
> 1) Implement a database of public keys and id's
> 2) I want to be able to add new (id, key) tuples dynamically
> 3) I want to be able to remove (id, key) tuples dynamically
> 4) I want to be able to perform lookups: id -> key
>
> This information is to be used for verification of signed binaries.
>
> What is my next step? I don't quite see how I can accomplish this using the
> ACI module since there is no rsbac_id_pubkey_aci_t structure. Is there a way
> to create my "custom" data base in a clean and simple manner? I guess it
> would be possible to add an rsbac_id_pubkey_aci_t structure, but that would
> make my module tightly coupled to RSBAC which is no good for any part (I
> maintenance nightmare?).
The standard solution is to have your own, possibly hashed, attribute list. An
example are the auth caps, implemented in auth_data_structures.[hc], or the
acl_data_structures.
The list functions are rather simple. RSBAC uses double linked lists for most
things, with lookup, add and remove functions, based on IDs. If persistent,
there is an interface function rsbac_write_<modname>, which is called by
rsbacd. The write function then flushes all dirty lists to disk.
Just have a closer look into auth and acl data structures. Don't get offended
by the number of lists in there, there is a lot of copy, paste and edit.
Amon.
-
To unsubscribe from the rsbac list, send a mail to
majordomo@rsbac.org with
unsubscribe rsbac
as single line in the body.
Next Article (by Author): Re: REG changes Amon Ott
Previous Article (by Author): REG changes Amon Ott
Top of Thread: Understanding ACI Jörgen Sigvardsson
Next in Thread: Re: Understanding ACI Jörgen Sigvardsson
Articles sorted by: [Date]
[Author]
[Subject]