|
The purpose of this daemon is to provide authorisation services for other
services. It can be used to authenticate and authorise entities to perform a
set of actions depending on their credentials and a policy.
Entities are identified by a public (RSA) key. They are authenticated using
a simple random (integer) number challenge. This means that they are required
to encrypt a random number with their private key and provide this information
along with their credentials. authd decrypts the data with the entity's public
key located in the credentials and checks if the result of the decryption
matches the random number (also called nonce). Since admission control is in
fact stateless (the only persistent state is the policy), the requesting
service is the one that must provide the random number to the entity for
encryption.
Authorisation of actions is performed based on the requested actions and the a
set of conditions specified in the credentials. The requested actions generate
assertions, which are checked against the conditions to determine their
validity.
Admission control uses the keynote trust-management system for authorisation.
Credentials and policies use the format defined by keynote. Furthermore
credentials can be delegated from one entity to another. For more information
please read the keynote man pages, and see RFC 2704.
Two types of actions are supported. They are quite generic in
nature and can be used for various purposes. These are: name-value pairs and
function calls.
- Name-value pairs are quite straightforward. A single assertion will be
generated assigning 'value' to 'name' and checking it against the conditions in
the credentials.
- Function call actions provide a generic way to authorise the execution
of any function by providing its name and a belonging library. Authorising a
function call also includes validating the arguments' values (See doc/
ASSERTIONS.txt for a list of the all the generated assertions). Currently
supported types for function arguments are: integer, float, string, unsigned
long long and function.
AUTHD uses shared memory IPC to receive requests and send results to services.
Only a single segment of memory is used for this purpose, thus semaphores are
used to synchronise processes accessing the shared memory segment. The shared
memory is writable by the user and group id authd is running as. This means
that for communication with AUTHD to be possible, the admission control clients
need to belong in the same group or run as the super-user id. More info in
authd(8) man page.
AUTHDFE is an optional front-end that can be compiled to provide a network
interface to AUTHD. OpenSSL is also supported. AUTHDFE is also needed to provide
interconnectivity with the kernel. More info in authdfe(8) man page.
libadmctrlcl.a, a client library for accessing admission control either
directly or through the front-end can is also provided. Instructions on how to
use the library can be found in doc/DEVELOPERS.txt and authd(3) man page.
authdev.o or authdev.ko is a linux kernel device driver that allows the kernel
to access AUTHd in user-space through AUTHDFE. This is accomplished by creating
a device file which the driver handles. The front-end is then using this file
to read requests, forward them to admission control and write results. Please
read the KERNEL MODULE section.
|
