I've looked at that paper a few times and I'm not sure I totally understand why it needs to be this complicated.
I would suggest you look at the Flume Appender as it is designed to implement a fast and secure solution for audit logging. In a nutshell, the appender converts to the LogEvent into a FlumeEvent. When Flume is invoked remotely the FlumeEvent is serialized using Avro. When Flume is embedded into the Appender it will write the event to the local disk - with the option of having the data encrypted while it resides on disk. The embedded appender will give control back to the application after the event is written to disk. The embedded Flume agent will then asynchronously forward the event on to its next hop and remove the event from the local disk once its receipt has been acknowledged. While you could use a RewritePolicy to add the information to the LogEvent, it strikes me that, like Flume, using the LogEvent for the purposes you seek may not be the best solution as it means the remote client has to know something about the internals of Log4j. Auditing is definitely a use case I believe Log4j should support so if you have other thoughts on this let's continue the discussion. Ralph On Nov 3, 2012, at 9:19 AM, Ralph Goers wrote: > I apologize for not responding sooner. This one somehow just slipped by. > > Please forgive me for not responding right now but I wanted to let you know > that I am going to read the paper again, but more thoroughly, so that I'm > sure I have a good idea of what you are looking to do. > > Ralph > > On Oct 25, 2012, at 12:12 AM, Jan Alsenz wrote: > >> Hello everyone! >> >> I originally joined the discussion at >> https://issues.apache.org/jira/browse/LOG4J2-100 , but this seems to be the >> better place for the current state of the idea. >> >> What I am looking for is a secure audit logging solution which employs >> cryptography to protect the audit log. One paper I found which describes >> what I am looking for can be found at >> http://www.schneier.com/paper-secure-logs.html . >> Unfortunately I didn't find any implementation of such a mechanism (neither >> in Java nor any other language). So I came looking for logging frameworks >> where it could be implemented as an add-on. >> >> For those too lazy or time constraint to read the paper a quick overview of >> what the idea is (the description is in chapter 3 with a nice picture on >> page 5): >> We have some log messages D_j we want to protect from tampering (and maybe >> also read access). To do that we generate an initial secret A_0, which is >> stored in volatile memory on the system and communicated to a secure system. >> A_0 is then used to calculate a MAC of D_0 (and can be used to derive an >> encryption key to encrypt D_0). Then A_1 is calculated with a one-way hash >> function (A_j+1=H(A_j)), overwrites A_0 and continues with the next message. >> >> What I want to build is a Log4J2 Plugin consisting of a RewritePolicy to add >> the checksum, MAC and encrypted message to the LogEvent and some converters >> to output the Audit entries. >> (In my setup I want to have encrypted/protected and unprotected logging in >> parallel, so simply replacing the message is not an option) >> >> Currently there are two main challenges for the implementation: >> - The previous A_j values must not be recoverable from the current system >> state, which is something very difficult to do with the Java GC. But this >> has nothing to do with Log4J and I'm pretty sure I already have a solution. >> - What is the best way to communicate the audit-information from the >> RewritePolicy to the converters? >> Solutions, that came up in the discussion were: subclassing Log4jLogEvent, >> adding a (serializable) attachment to LogEvent or subclassing various >> Message types. >> >> So my main question is what would be the best way for the internal >> communication? >> >> Subclassing Log4jLogEvent in currently not compatible with the >> AsynchAppender and the existing RewritePolicies and would require code >> changes to the core (a possible path was proposed in the mentioned issue). >> Additionally there may be problems if the LogEvents are communicated outside >> of the current JVM (Java serialization). >> Adding an attachment to the LogEvent would also require code changes, but >> could be made compatible with outside JVM communication relatively easy and >> would be unobtrusive for any other component. >> Subclassing Messages I am still investigating, but it is possible that >> similar issues as with subclassing Log4JLogEvent show up. >> >> To my current knowledge LogEvent attachments seem to be a nice option, as I >> said my analysis is not finished yet and any additional ideas are very >> welcome! >> >> Best Regards, >> >> Jan >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org >> For additional commands, e-mail: log4j-dev-h...@logging.apache.org >> > --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
