On Sun, 13 Dec 2015 22:19, Alice Wonder wrote:
On 12/13/2015 12:45 PM, Valeri Galtsev wrote:
On Sun, December 13, 2015 11:36 am, Alice Wonder wrote:
On 12/13/2015 08:39 AM, Timothy Murphy wrote:
Alice Wonder wrote:
One of the benefits of systemd is the dependency based parallel
startup.
The same speed can often be achieved with system V init by fine tuning
when the services start but systemd does that automatically.
If it's no faster then why is it a benefit?
Binary logs with checksums is one benefit, much harder for a hacker or
malware to hide its tracks.
Without intent to be a pain in a... just respectfully disagreeing.
Harder only from the point of view current tools script kiddies use will not deal with then. Fundamentally better security/forensics wise would be to keep logs on remote secure server. Like in the very first computer security lesson: you can not trust anything on compromised machine.
It's a matter of knowing your machine has been compromised.
Modifying the binary logs to hide that you are there will result in checksum inconsistencies, removing a few lines from text logs will not.
Yes, you can use text log to a remote machine to avoid that, but binary logs let you on the local machine.
Well, in the ideal case, yes. BUT, as it is, the binary log that systemd-journald, becomes compromised, and unreadable too often to be helpful.
From a compromised journald log file you get NOTHING at all.
You can't even get the entries up until the point the compromise of the log happend. Not helpful.
All you can see is that you cant view the log at all. Bravo. And why that has happend? Was it the filesystem, was it journald itself, was there a break-in, did someone local try to manipulate the log?
Where is your answer?
Sorry, nice idea but very ugly result, not useable as intended.
Yes, I'm frustated with journald, for production I'm using remote logging with TLS and oneway replicated database, locally either syslog-ng or rsyslog.
I'll keep an eye on it, but atm it's not useable for me on disk.
- Yamaban.