From owner-freebsd-hackers@FreeBSD.ORG Fri May 25 09:23:20 2007 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0C14916A421; Fri, 25 May 2007 09:23:20 +0000 (UTC) (envelope-from Martin.Englund@Sun.COM) Received: from gmp-ea-fw-1.sun.com (gmp-ea-fw-1.sun.com [192.18.1.36]) by mx1.freebsd.org (Postfix) with ESMTP id 83B8D13C44C; Fri, 25 May 2007 09:23:19 +0000 (UTC) (envelope-from Martin.Englund@Sun.COM) Received: from d1-emea-10.sun.com (d1-emea-10.sun.com [192.18.2.120]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4P8HG16023500; Fri, 25 May 2007 08:17:16 GMT Received: from conversion-daemon.d1-emea-10.sun.com by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JIL00H0187YDY00@d1-emea-10.sun.com> (original mail from Martin.Englund@Sun.COM); Fri, 25 May 2007 09:17:16 +0100 (BST) Received: from [192.168.10.111] ([81.227.51.162]) by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JIL001UT8CPEVHB@d1-emea-10.sun.com>; Fri, 25 May 2007 09:17:16 +0100 (BST) Date: Fri, 25 May 2007 10:16:50 +0200 From: Martin Englund In-reply-to: <200705250322.22259.karma@FreeBSD.org> Sender: Martin.Englund@Sun.COM To: karma@FreeBSD.org, Tomas Zeman Message-id: <3F513D30-D359-46E5-B23E-55A02D9DF70E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.752.3) Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII Content-transfer-encoding: 7BIT References: <200705250322.22259.karma@FreeBSD.org> X-Mailman-Approved-At: Fri, 25 May 2007 11:28:42 +0000 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 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2007 09:23:20 -0000 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 and Robert Watson 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."