SoC: Distributed Audit Daemon project

[Martin Englund]

Hi Alexey!

I think your project would be beneficial to both FreeBSD &  
OpenSolaris. Tomas Zeman is working on a similar thing for  
OpenSolaris, and I think it would be very good if you could use the  
distributed audit daemon to gather audit trails from both operating  
systems!

On May 25, 2007, at 01:22 , Alexey Mikhailov wrote:

> 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. */
>
> _______________________________________________
> trustedbsd-discuss at FreeBSD.org mailing list
> http://lists.freebsd.org/mailman/listinfo/trustedbsd-discuss
> To unsubscribe, send any mail to "trustedbsd-discuss- 
> unsubscribe at FreeBSD.org"

cheers,
/Martin
-- 
Martin Englund, Java Security Engineer, Java SE, Sun Microsystems Inc.
Email: martin.englund at sun.com Time Zone: GMT+2 PGP: 1024D/AA514677
"The question is not if you are paranoid, it is if you are paranoid  
enough."