Devuan 2.1 Released - Still Delivering Debian 9 Without Systemd

[aht0]

It can not really be "tamper-proof". Systemd is open source, thus writing something capable reading/modifying it's binary logs is far from impossible. Methods are after all, freely readable from systemd's source, isnt it so?
Once someone has rough proof-of-concept done, you can expect malware armed with it.

[Danielsan]

Danielsan

You're talking about systemd the system manager. systemd the init system (AKA PID1) isn't much more complicated than any other init system.

From the description doesn't seem so simple...

system and service manager
 systemd is a system and service manager for Linux. It provides aggressive
 parallelization capabilities, uses socket and D-Bus activation for starting
 services, offers on-demand starting of daemons, keeps track of processes using
 Linux control groups, maintains mount and automount points and implements an
 elaborate transactional dependency-based service control logic.

Rather than:

[URL="http://smarden.org/runit/runit.8.html"]runit[/URL] performs the system's [I]booting[/I], [I]running[/I] and [I]shutting down[/I] in [B]three stages[/B]

[intelfx]

From the description doesn't seem so simple...

system and service manager
systemd is a system and service manager for Linux. It provides aggressive
parallelization capabilities, uses socket and D-Bus activation for starting
services, offers on-demand starting of daemons, keeps track of processes using
Linux control groups, maintains mount and automount points and implements an
elaborate transactional dependency-based service control logic.

Rather than:

[URL="http://smarden.org/runit/runit.8.html"]runit[/URL] performs the system's [I]booting[/I], [I]running[/I] and [I]shutting down[/I] in [B]three stages[/B]

Let me try:

systemd does stuff so your system works

Can’t beat that.

[intelfx]

It can not really be "tamper-proof". Systemd is open source, thus writing something capable reading/modifying it's binary logs is far from impossible. Methods are after all, freely readable from systemd's source, isnt it so?
Once someone has rough proof-of-concept done, you can expect malware armed with it.

There’s this weird thing called “cryptography”.

Security by obscurity is irrelevant.

[aht0]

intelfx

I agree with your latter statement.

Now my question tho : In what particular way systemd's implementation of forward-sealing differs from "obscurity"?

Cryptographic method in question originates from Lennart's own brother's research paper (Bertram was co-author) which was cutting edge at the time of implementation - which means that it had received zero auditing about potential weaknesses - he just grabbed the idea and ran with it. You DO NOT implement security critical cryptograhy "just like that" in a system component which has total control over computer. I am pretty sure bright brains in NSA, MSS and FSB/SVR have gone over that implementation (and systemd as a whole for that matter) with fine-toothed comb and had bunch of orgasms while figuring out what, where and how to exploit.

For that matter, systemd logs can simply be corrupted, once done - any further tampering is meaningless.

[intelfx]

Now my question tho : In what particular way systemd's implementation of forward-sealing differs from "obscurity"?

In every way. As I said, there is this weird thing called "cryptography"... Do you even know what "security by obscurity" is?

Cryptographic method in question originates from Lennart's own brother's research paper (Bertram was co-author) which was cutting edge at the time of implementation - which means that it had received zero auditing about potential weaknesses - he just grabbed the idea and ran with it. You DO NOT implement security critical cryptograhy "just like that" in a system component which has total control over computer. I am pretty sure bright brains in NSA, MSS and FSB/SVR have gone over that implementation (and systemd as a whole for that matter) with fine-toothed comb and had bunch of orgasms while figuring out what, where and how to exploit.

Tinfoil-hatting is irrelevant. Please demonstrate an attack.

For that matter, systemd logs can simply be corrupted, once done - any further tampering is meaningless.

Any logs can be corrupted (for example, outright removed, which is a special case of corruption). Usually, however, the goal of an attacker is to stay undetected as long as possible, which is where tamper resistance comes into play.

[aht0]

In every way. As I said, there is this weird thing called "cryptography"... Do you even know what "security by obscurity" is?

Could at least ONE of the systemd fanboys get by without instantly going personal? Yes, I know what "security by obscurity" is. And in my opinion using unproven cryptography for security purposes is flat out dangerous and not too smart. If used cryptograhic solution is breakable it's exactly that - security by obscurity - because there's no real security FROM cryptography, just breakable obscurity..

Tinfoil-hatting is irrelevant. Please demonstrate an attack.

Are you able to write malware? If not, then tinfoil-hatting is irrelevant (and you don't need antivirus even on Windows). Read it again, can you feel how stupid such mental approach is?

I don't need to be able to write malware in order to be aware of the general danger while using computer. Finding flaws in cryptography is one area where just knowing basic math is not enough, you'll have to know math really damn well, have to know theories behind cryptography and be able to do cryptoanalysis. It's the reason why people often use some technical solution for years before some scientist or researcher happens to find critical weakness. Often the solution may be theoretically sound enough but implementation sucks or keys used are weak.

Good security practice is not to use untested crypto right away, not in critical tasks, one should let people with cryptoanalysis and math backgrounds to try and find vulnerabilities.

Any logs can be corrupted (for example, outright removed, which is a special case of corruption). Usually, however, the goal of an attacker is to stay undetected as long as possible, which is where tamper resistance comes into play.

When logging facility itself has nasty tendency of occasionally corrupting logs, attacker may just as easily just intentionally corrupt particular logs and still remain.. undetected.
Because admin would shrug it just off as "shit happened, it's normal". Especially, it may not have been logging facility causing corruption but something else, like bad block on drive or error in file system. Following that train of thought, whatever you may do with the local log files, there's no final quarantee, Forward-seal under questionable crypto may actually instill false sense security so that admin never bothers setting up remote logging.

[intelfx]

Could at least ONE of the systemd fanboys get by without instantly going personal? Yes, I know what "security by obscurity" is. And in my opinion using unproven cryptography for security purposes is flat out dangerous and not too smart. If used cryptograhic solution is breakable it's exactly that - security by obscurity - because there's no real security FROM cryptography, just breakable obscurity..

Claiming that systemd uses unproven cryptography when sealing logs would be valid criticism. Claiming that it's "security by obscurity" — isn't (which is what you implied when you claimed that "Systemd is open source, thus writing something capable reading/modifying it's binary logs is far from impossible. Methods are after all, freely readable from systemd's source, isnt it so?").

Besides, I'm not going personal (I'm merely asking to avoid a misunderstanding), but you are.

Are you able to write malware? If not, then tinfoil-hatting is irrelevant (and you don't need antivirus even on Windows). Read it again, can you feel how stupid such mental approach is?

You said that "you were sure". If you are so "sure", then please demonstrate an attack or at least an approach.

When logging facility itself has nasty tendency of occasionally corrupting logs, attacker may just as easily just intentionally corrupt particular logs and still remain.. undetected.
Because admin would shrug it just off as "shit happened, it's normal". Especially, it may not have been logging facility causing corruption but something else, like bad block on drive or error in file system. Following that train of thought, whatever you may do with the local log files, there's no final quarantee, Forward-seal under questionable crypto may actually instill false sense security so that admin never bothers setting up remote logging.

You said it yourself — bugs can happen anywhere in the stack. If anything, journals at least give you means to check for corruptions; plain text, not so sure. If you are a diligent admin, then you will investigate every corruption. And if you are forward-sealing (or otherwise signing) your logs, then yes, you absolutely have to investigate every broken signature as if it were an attack.

The question of whether the crypto is trustworthy is orthogonal. Nobody is forcing you to use it, and nobody is forcing you to use journal sealing as your only line of defense.

[aht0]

Claiming that systemd uses unproven cryptography when sealing logs would be valid criticism.

Okay, that's at least where we are on common ground.

Claiming that it's "security by obscurity" — isn't (which is what you implied when you claimed that "Systemd is open source, thus writing something capable reading/modifying it's binary logs is far from impossible. Methods are after all, freely readable from systemd's source, isnt it so?").
Besides, I'm not going personal (I'm merely asking to avoid a misunderstanding), but you are.

If you look upwards and read it over again word-by-word, you'll notice it wasn't quite what I said. There was one important conditional altering the meaning subtly.

And in my opinion using unproven cryptography for security purposes is flat out dangerous and not too smart. If used cryptograhic solution is breakable it's exactly that - security by obscurity - because there's no real security FROM cryptography, just breakable obscurity..

I wasn't using 'when' there, I used 'if'. Which shows I considered it as probability, not quaranteed when.
But there are real dangers in using untested crypto right out of the hat. Most security researchers you can trust report and not to abuse bugs. There's huge black market for 0-day exploits, which aren't going to be reported when found but sold to highest bidder in dark web. Certain subset of security researchers have literally based their livelyhoods on finding and selling such vulnerabilities. Which, once sold, end up being used in malware for maximum effect.

You said that "you were sure". If you are so "sure", then please demonstrate an attack or at least an approach.

Potential weakness(es) in algorithm(s), weak key(s), programming error(s) [which are quaranteed to happen], brute force attacks using quantum computers - uhm, can you claim forward-sealing to be quantum-safe? If not then applying quantum computing means that crypto might as well not be there at all. Intelligence agencies (at least U.S and Chinese should have quantum computing capability for some time now, considering that first models have been reaching public over the past few years, tech available for intelligence is generally well-ahead of what could be available for public even for obscene amount of money)
I'll give you fun fact: who's RHEL's largest customer?: U.S military-industrial/government complex. Verified by US Army's Maj.General Nicholas Justice, who happened to come public with that tidbit of information.

You said it yourself — bugs can happen anywhere in the stack. If anything, journals at least give you means to check for corruptions; plain text, not so sure. If you are a diligent admin, then you will investigate every corruption. And if you are forward-sealing (or otherwise signing) your logs, then yes, you absolutely have to investigate every broken signature as if it were an attack.

Agree.
But then we may see some new CVE's, which would allow attacker to crash systemd component(s) and achieve priv.escalation. Let's recall CVE-2018-16864, CVE-2018-16865 and CVE-2018-16866. Quite recent actually (less than a year). These caused systemd-journald ITSELF to crash and enabled takeover of a system.

My preferred approach would be "less code, less feature creep". systemd is actually awesome idea but it's design and implementation have proven to be disgusting show of "let's try this & we know better & this is feature not a bug & we won't fix". RHEL should have sub-contracted development of systemd to OpenBSD devs ˇˇ

The question of whether the crypto is trustworthy is orthogonal. Nobody is forcing you to use it, and nobody is forcing you to use journal sealing as your only line of defense.

Yes. But once it was presented as an argument supposedly proving systemd's inherent superiority, it had to be dissected at length, right?

[intelfx]

If you look upwards and read it over again word-by-word, you'll notice it wasn't quite what I said. There was one important conditional altering the meaning subtly. I wasn't using 'when' there, I used 'if'. Which shows I considered it as probability, not quaranteed when.

What you said is still wrong. First, using breakable crypto is just that, breakable crypto. It's still crypto. Second, you do not know if journald's crypto is breakable. Third, you know about such thing as "editorial synthesis"? You may not have said that "journald log sealing is security by obscurity", but you strongly hint at that. Which is false.

Potential weakness(es) in algorithm(s), weak key(s), programming error(s) [which are quaranteed to happen]

Programming errors can happen in any software. Potential weaknesses can happen in any invented algorithm. You cannot use "what-ifs" as a valid criticism.

brute force attacks using quantum computers - uhm, can you claim forward-sealing to be quantum-safe? If not then applying quantum computing means that crypto might as well not be there at all.

Again, wrong. You cannot judge an algorithm by its resilience to yet-unknown or yet-impossible types of attacks. "What if there was an attack that breaks all known crypto? Then all known crypto is worthless, uh-oh!" It's an unproductive way to lead a discussion. There are no known attacks on journald log sealing, period.

Intelligence agencies (at least U.S and Chinese should have quantum computing capability for some time now, considering that first models have been reaching public over the past few years, tech available for intelligence is generally well-ahead of what could be available for public even for obscene amount of money)
I'll give you fun fact: who's RHEL's largest customer?: U.S military-industrial/government complex. Verified by US Army's Maj.General Nicholas Justice, who happened to come public with that tidbit of information.

<tinfoiling skipped>

But then we may see some new CVE's, which would allow attacker to crash systemd component(s) and achieve priv.escalation. Let's recall CVE-2018-16864, CVE-2018-16865 and CVE-2018-16866. Quite recent actually (less than a year). These caused systemd-journald ITSELF to crash and enabled takeover of a system.

Vulns happen.

If anything, then systemd is significantly better protected against vulnerabilities than absolute majority of other software out there. See all those settings in journald's unit file? journald is sandboxed to hell and back. I'm not even sure if those CVEs are actually exploitable.

My preferred approach would be "less code, less feature creep".

Let's just throw out computers? No code, no vulnerabilities possible whatsoever. You see, all that code actually does useful things. If you throw out some code from systemd, you will have to add it back somewhere.

systemd is actually awesome idea but it's design and implementation have proven to be disgusting show of "let's try this & we know better & this is feature not a bug & we won't fix".

Are we still talking about security or you're just venting at this point that systemd closed your favorite bug as WONTFIX? And yes, what's wrong with design of systemd? Point by point.

Yes. But once it was presented as an argument supposedly proving systemd's inherent superiority, it had to be dissected at length, right?

I don't know anything about "inherent" superiority. Log sealing is just a secondary feature in one of the optional components of the systemd suite. And yes, I'm all for dissecting at length, but the quality of your dissection is honestly lacking.