Announcement

Collapse
No announcement yet.

Devuan 2.1 Released - Still Delivering Debian 9 Without Systemd

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

  • #51
    Originally posted by Spam View Post
    The journal system is by far the most hideous to me. Why on earth have binary logs that are difficult to read in case you need recovery options....
    Because proprietary binary logs are tamper proof, while I one could easily manipulate a regular text file.

    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.

    Comment


    • #52
      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.

      ​​​​
      ​​​​​

      Comment


      • #53
        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:
        runit performs the system's booting, running and shutting down in three stages

        Comment


        • #54
          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:
          runit performs the system's booting, running and shutting down in three stages
          Let me try:

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

          Comment


          • #55
            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.

            Comment


            • #56
              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.

              ​​​​​

              Comment


              • #57
                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.

                Comment


                • #58
                  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.

                  Comment


                  • #59
                    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; 12-08-2019, 11:18 PM.

                    Comment


                    • #60
                      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?

                      Comment

                      Working...
                      X