Security by obscurity never works.

1 members found this post helpful.

I'm sure I heard a collective sigh of relief when you left.

Do you really think you can trust your logs after a hack & break-in? Even with tagged and signed logs, the hacker will either use his hacker tools to violate your records or will just delete all logs and therefore will leave you out in the cold.
Do not underestimate the criminal hacker scene. That is a hidden IT industry turning around many millions of dollars a year, which produces tools which are as good or better than any white-hat forensics tools.

Exactly.

I am not underestimating. But encrypting log files makes lots of sense to slow them down... Hey then why use /etc/shadow? The hacker will decrypt it anyways right? lets just give up on security since everything is insecure and not worry about encryption from now on. Hackers can crack it anyway...
I'm not trying to sound condescending but this is the logic of what you are saying. If he decides to delete them... then you don't think the admin will notice?
There is no way to justify this imo.

Obfuscating a logging facility actually makes it easer to cover tracks. It's not about deleting logs, its about hiding activities. A whole malware industry lives off the fact, that Windows is opaque, mostly undocumented and has its configuration and logs stored in BLOBs. The only people that really know this stuff in-depth (including knowledge gained by reverse engineering) are the black hats.

You can be sure, that within weeks your rootkit programmer next door knows more about systemd/journald and its undocumented features than your regular sysadmin, who can't even tell, if the output of the fancy frontend tool has anything to do with the real content of the "journal".

1 members found this post helpful.

I'll just simply ignore systemd until it goes away -I have already done just that with other such things. Even udev itself could go that way. I won't be too worried until something like this shows up in the kernel:

2 members found this post helpful.

Since there seems to be a misconception about it, I'll kindly point out that using systemd's journal is *not* required. You can simply ignore the journal all together, and the data it stores ( sitting in /run by default ) will sit and consume little to no space (10mb max by default, iirc? and configurable), and be wiped away at boot.

syslogging continues to work exactly how it does today. Again, projects like rsyslog even go so far as to provide native systemd files. Of course, in large scale operations which depend on heavy log monitoring, the standard system logger will never go away. And it's not the intention of systemd to ever do so.

Personally? I agree that the binary log format is a little strange. But as a single-user on my laptop, the journal has completely made a system logger obsolete. I can ask systemd about a service, and it tells me the state of the the service, and even pops up the last few entries regarding that service that the journal has seen. It's really, really neat in practice.

Again, it's all about choice. systemd has really cool stuff built in which caters a little easier to the standard user, but in the event you want the kitchen-sink solution, it works just as well.

Please someone decypher this for me. I can't seem to understand the reasoning of what you are trying to say.

Leaving the log files as text simply cp a snapshot of logs then to upload new one makes great sense for a hacker. The admin can just log on and walla! Nothing happened in my logs, my system is secure carry on... (admin)

Oh now you are going to say the dates? and time file is created?

So hackers can hack the systemd encryption and all the added security features but can't manipulate dates to files?

You are talking to an exhacker here.

lets not get into the improvements in processes and startup in deamons. let me continue studying i will end up here forever again.

The efficacy of /etc/shadow is not that the passwords within it are encrypted (they were encrypted when they were originally in Unix's /etc/passwd), it is that /etc/shadow is only readable by root (/etc/passwd is world readable).

If your concern is in "slowing down" hackers who have gained root privilege, you should rethink your security model.

2 members found this post helpful.

You should have said so earlier in the thread, I'd have doffed my cap......

+1

what is the point of the Shadow file passwords being encrypted then? I'm about to break LQ rules by cursing you out here...
Hackers can crack it anyway right?
True...

so why encrypt it? Why encrypt anything if hackers can crack it so easily.

You think the log files for systemd is world readable?

(added: I am assuming that you don't think there are exploits to escalate permission priveledges huh?)

So lets all just depend on UNIX File Permissions... is that the way you deal with security here?

Common man.... im out! Too much nonsense in here!

By keeping things simple, people defending their systems can be on par with the potential attackers. Make a system unique and you can even gain an advantage, because you know your individual environment, your attacker does not.

By standardizing on an unneeded complex solution, the black hats always gain an advantage even over experienced users. The attackers always understand more about complex opaque stuff, because they are smart -- some of them are even smarter than Poettering.

That's the whole point of the KISS philosophy regarding IT security.

2 members found this post helpful.

If that is what you believe to be true to not encrypt log files more secure then plain text (simple files)... i sure won't be hiring you anytime soon.

The distinction is that there is no reason for the root account (or any other) to know a user's password, there are valid reasons for root to examine log files (else why would you even maintain them).


You keep using that word. I do not think it means what you think it means. (Though I appreciate that you consider me not to be "elitist".)