Date: Fri, 25 May 2007 10:16:50 +0200 From: Martin Englund <Martin.Englund@Sun.COM> To: karma@FreeBSD.org, Tomas Zeman <Tomas.Zeman@Sun.COM> Cc: freebsd-hackers@FreeBSD.org, trustedbsd-audit@FreeBSD.org, audit-discuss@opensolaris.org, trustedbsd-discuss@FreeBSD.org, karma@ez.pereslavl.ru Subject: Re: SoC: Distributed Audit Daemon project Message-ID: <3F513D30-D359-46E5-B23E-55A02D9DF70E@sun.com> In-Reply-To: <200705250322.22259.karma@FreeBSD.org> References: <200705250322.22259.karma@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@FreeBSD.org mailing list > http://lists.freebsd.org/mailman/listinfo/trustedbsd-discuss > To unsubscribe, send any mail to "trustedbsd-discuss- > unsubscribe@FreeBSD.org" cheers, /Martin -- Martin Englund, Java Security Engineer, Java SE, Sun Microsystems Inc. Email: martin.englund@sun.com Time Zone: GMT+2 PGP: 1024D/AA514677 "The question is not if you are paranoid, it is if you are paranoid enough."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3F513D30-D359-46E5-B23E-55A02D9DF70E>