I don't know that logback has any kind of direct solution, though I'm sure that a bug report would at least get some reasonable consideration.
On the other hand, logging to a database might help, or using a more complicated format for log entries ( http://logback.qos.ch/manual/encoders.html - see the section on PatternLayoutEncoder) would make it easier to pick out fake log entries. Adding a time tag would make it significantly more difficult to forge an entry - it would be easy enough to verify that the time tags in the file are all in the correct order. Out of order entries would be obvious fakes. In any case, I absolutely would also look at addressing this problem on the input side, as well. On Tue, Aug 13, 2013 at 1:01 PM, kommersz <[email protected]> wrote: > > Hi Logback people, > > I am now looking for a logging solution to use in a larger piece of > software, which would provide protection against Log Forgery ( > http://cwe.mitre.org/data/definitions/117.html), even in cases when > logging to a text file is configured (log forgery is basically about > strings containing linefeeds being passed over to the logging framework - > if the srings are manipulated in the right way, the new entries look like > if they were "real" log entries) > I already had a look at log4j, and talked to some people, but to me it > seems that they do not offer, and do not want to offer any sort of > protection. So I would like to consider now Logback - and hence the > question: is Logback offering any sort of solution, or is any solution > planned? > > Cheers, > Gabor > > > > _______________________________________________ > Logback-user mailing list > [email protected] > http://mailman.qos.ch/mailman/listinfo/logback-user > -- Family photographs are a critical legacy for ourselves and our descendants. Protect that legacy with a digital backup and recovery plan.
_______________________________________________ Logback-user mailing list [email protected] http://mailman.qos.ch/mailman/listinfo/logback-user
