Announcement

Collapse
No announcement yet.

In 2019, Most Linux Distributions Still Aren't Restricting Dmesg Access

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

  • #31
    To be honest, locking down dmesg feels like the Linux equivalent of those The Old New Thing posts about clients trying to report supposed Windows security vulnerabilities that get WONTFIX'd because "they're already on the other side of the airtight hatch" and the fix would require drastic changes.

    (The kind of thing where the reproduction instructions often begin with putting a malicious DLL somewhere that requires permissions that already allowed much less convoluted exploits... such as just attacking the EXE being compromised in the first place.)

    ...in no small part because dmesg is important for efficiently diagnosing things like "Device was plugged into a bad/too-slow USB hub/cable".

    Why not just fix it properly by having a sysctl to hide memory addresses from dmesg instead?

    Comment


    • #32
      Enabling secure boot automatically locks down dmesg.
      And it locks down other security related things as well (suspend to disk).
      I´m glad kernel folks will soon add more lockdowns that also will be available to none secure boot users.
      Besides, there is so much more to do to get a reasonably safe machine.
      Mandatory access control is such an important mechanism, protect at least your web browser and email client. I love AppArmor. It´s simple and straight forward. Better also protect your PDF reader and favourite virtualizer solution with MAC.
      Locking down dmesg won´t stop a serious intruder.
      The larger your minefield, the better.

      Comment


      • #33
        Originally posted by hreindl View Post

        idiots don't realize the importance of secure defaults, smart guys know sysctl and fstab and don't rely on defaults
        (...)
        What about these 2:
        net.ipv4.tcp_timestamps = 0
        kernel.kexec_load_disabled = 1

        proc hidepid could break lot stuff, especially virtualizers I guess? I´d rather block PROC an a per app basis with AppArmor. E.g. granting VirtualBox access and deny for firefox.

        Comment


        • #34
          Originally posted by hreindl View Post

          idiot! security comes in layers
          For once I agree.

          Comment


          • #35
            Originally posted by sandy8925 View Post
            That's a bad justification - it's security by obscurity. If the kernel can be hacked through userspace processes, just because you know some small piece of information, then that implies bad security design/bugs.
            There's nothing wrong with security-by-obscurity as such – denying information to an attacker is always good practice. The problem is in relying on obscurity alone, instead of treating it as just one part of good security process. Bugs happen, so if blocking information in dmesg can prevent an attacker from exploiting a bug that's not been found and fixed, then blocking it doesn't sound such a dumb idea, does it?

            Comment


            • #36
              Originally posted by hreindl View Post
              idiot! what has this to do with virtualbox?
              Did you even read the article you dumbfuck?

              Comment


              • #37
                Originally posted by Weasel View Post
                Did you even read the article you dumbfuck?
                Oracle's VirtualBox was highlighted as one of
                AKA there are more, VB was just one example.

                Comment


                • #38
                  So many alternatively gifted wanna-be security professionals/researchers here it's mind boggling.

                  First of all, dmesg can be run only by local users - it's inaccessible remotely.

                  Secondly, if the malicious actor has a shell on your PC you're already royally f*cked (think key logging, desktop screenshot'ing, traffic sniffing, etc.) and hiding `dmesg` is completely useless.

                  Thirdly, a LOT of dmesg data/information can be easily fetched from /proc, /sys and by running certain shell commands. Like over 95% of it.

                  Fourthly, I've been using Linux for over 20 years and I have never heard of a single security/privacy issue related to (the) dmesg (output) being available to non-root users. Not a single f*cking case.

                  What a dumb mess we have here. LOOOL.

                  Phoronix commentators never cease to amaze with their idiocy.

                  Comment


                  • #39
                    Originally posted by Fernseher View Post
                    Enabling secure boot automatically locks down dmesg.
                    Solely depends on your distro, so you're lying:

                    Code:
                    [[email protected] hp]$ id
                    uid=1000(birdie) gid=1000(birdie) groups=1000(birdie) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
                    [[email protected] hp]$ dmesg | grep -i secure
                    [    0.000000] secureboot: Secure boot enabled
                    [    0.000000] Kernel is locked down from EFI secure boot; see man kernel_lockdown.7

                    Comment


                    • #40
                      Originally posted by Luke_Wolf View Post
                      Security theater at it's best.

                      To exploit this requires a compromised user account and having a kernel exploit to actually do anything. If they're that far you're already screwed.

                      Meanwhile the information is very useful to have for users to diagnose what's going wrong with their machine.
                      Wow, there are some sane people here.

                      Comment

                      Working...
                      X