SoC: Distributed Audit Daemon project

[Alexey Mikhailov]

Hello!

I'm the SoC student who will work on "Distributed Audit Daemon"
project this summer. It was some discussion between me, my mentor
Bjoern Zeeb <bz@> and Robert Watson <rwatson@> about design of
this project. In this message I want to describe preliminary version
of design we're likely to have. Your criticism and comments are
very welcome!

Some general theses first.

1. What this project is about?

The general idea is to make it possible to log auditable events
to remote hosts by secure network transport. Some basic association
is daemon that acts as the server which receives BSM messages and
writes them out to local filesystem. and acts as client which
send BSM messages out.

My initial proposal on this project can be found here:

http://wiki.freebsd.org/DistributedAuditDaemon

2. As I said before initial subject of this project was "Distributed
audit daemon". But after some discussions we had decided that this
project can be done in more general maner. We can perform distributed
logging for any user-space app. At this rate we need to get clean
and general design with good level of abstraction. It seems that
"Distributed logging daemon" is the good name for this project.
(I will refer as "dlogd" to it)

Consider this picture ( Yes, I know that my ASCII art sucks :-) )

'----------------`                       '-----------------`
|                |      '---------`      | Client-specific |
| User-space app | <==  | API [2] | ==>  |     part of     |
|     [1]        |      `---------'      |   "dlogd" [3]   |
`----------------'                       `-----------------'
                                                ^^
                                                ||
                                                ||
                                                
                                           (network level) [4]

                                                ||
                                                ||
                                                vv
                                         '-----------------`
             '===============`           | Server-specific |
             |  File system  | <======== |    part of      |
             | hierarchy [6] |           |    "dlogd" [5]  |
             `==============='           `-----------------'

Now I'll describe processes that will take place according to
this scheme.

[1] <=> [2]: Shared user-space library will incapsulate API.
And I really want to keep real API simple. At this moment
I'm going to have only one function that will mark log file
as "to deliver" (i.e. dlogd_submit("/var/audit/whatever")).

[2] <=> [3]: IPC will be UNIX domain sockets (PF_LOCAL).

Authentication scheme for this is:

  (1) Authenticate [3] to [2]. This is reasonably authenticated
  by using a trusted name  for the local socket, such as
  /var/dlogd/socket.  Only a process authorized to act as the daemon
  will be able to create the socket.

  (2) Authenticate [2] to [3]. With UNIX domain sockets, a credential
  can be passed on connection, which we should do.

When [3] receives file name logX, it makes symbolic link (it could
be hard to preserve deletion but there're some issues with it) from
logX to /var/dlogd/spool/audit/logX. Every T seconds [3] pushes
spool out to [4] and logs succesful transactions. We can have some
policies here, e.g.

  * Transaction fails: if (current_time - log file timestamp) > T_1
    then remove log file from spool and log it

  * Transaction success: schedule log file removing for T_2 period

[3] <=> [4]: At the network level we're going to use SSL certificates
for authentication.

[4] <=> [5]: We peform certification-based authentication here. And
good point is to use administrator-assigned names here based on it.
(if those corresponds to hostname or IP addresses -- that's fine)

[5] <=> [6]: If authentication went OK we receive log file and log
it to physical filesystem considering client name that we would get
at previous step.

Open questions:

1) Do we need some non-trivial network protocol in [3] <=> [5]
communication or we can just send log file content preceded by
size and name? (For example, server can ask client for missing log
files, or send message that it's alive again after some crash or
something)

2) Do we need some non-trivial API that I mentioned in [1] <=> [2]
step? Non-trivial API could be something like

dlogd_flush("/var/audit");            /* Notify of fresh start. */
dlogd_created("/var/audit/whatever"); /* Notify of creation. */
dlogd_submit("/var/audit/whatever");  /* Notify of termination. */