Announcement

Collapse
No announcement yet.

Devuan 2.1 Released - Still Delivering Debian 9 Without Systemd

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • intelfx
    replied
    Originally posted by aht0 View Post
    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.

    Originally posted by aht0 View Post
    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.

    Originally posted by aht0 View Post
    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.

    Originally posted by aht0 View Post
    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>

    Originally posted by aht0 View Post
    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.

    Originally posted by aht0 View Post
    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.

    Originally posted by aht0 View Post
    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.

    Originally posted by aht0 View Post
    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.

    Leave a comment:


  • aht0
    replied
    Originally posted by intelfx View Post
    Claiming that systemd uses unproven cryptography when sealing logs would be valid criticism.
    Okay, that's at least where we are on common ground.

    Originally posted by intelfx View Post
    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.

    Originally posted by intelfx View Post
    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.

    Originally posted by intelfx View Post
    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 ˇˇ

    Originally posted by intelfx View Post
    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?

    Leave a comment:


  • intelfx
    replied
    Originally posted by aht0 View Post
    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.

    Originally posted by aht0 View Post
    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.

    Originally posted by aht0 View Post
    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.
    Last edited by intelfx; 08 December 2019, 11:18 PM.

    Leave a comment:


  • aht0
    replied
    Originally posted by intelfx View Post
    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..

    Originally posted by intelfx View Post
    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.

    Originally posted by intelfx View Post

    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.

    Leave a comment:


  • intelfx
    replied
    Originally posted by aht0 View Post
    ​​​​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?

    Originally posted by aht0 View Post
    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.

    Originally posted by aht0 View Post
    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.

    Leave a comment:


  • aht0
    replied
    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.

    ​​​​​

    Leave a comment:


  • intelfx
    replied
    Originally posted by aht0 View Post
    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.

    Leave a comment:


  • intelfx
    replied
    Originally posted by Danielsan View Post

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

    Code:
    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:

    Code:
    [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:

    Code:
    systemd does stuff so your system works
    Can’t beat that.

    Leave a comment:


  • Danielsan
    replied
    Originally posted by unixfan2001 View Post

    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...

    Code:
    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:

    Code:
    [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]

    Leave a comment:


  • aht0
    replied
    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.

    ​​​​
    ​​​​​

    Leave a comment:

Working...
X