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

  • #41
    Originally posted by birdie View Post
    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.
    Some notes:

    - If dmesg output contains the description of a software or hardware fault, an attacker might in theory use this description to decide how to best attack the system.

    - A major part of security is about preventing possible attacks (theoretical attacks), which means that many security measures applied to a machine never get activated/triggered.

    - I don't understand why you are using vulgarisms in your posts. You could try to learn to resist the urge to use them, with time.

    Comment


    • #42
      Originally posted by Luke_Wolf View Post
      Meanwhile the information is very useful to have for users to diagnose what's going wrong with their machine.
      Fixing such a problematic machine usually requires root access or physical access to the hardware.

      Comment


      • #43
        Originally posted by atomsymbol View Post
        Some notes:

        - If dmesg output contains the description of a software or hardware fault, an attacker might in theory use this description to decide how to best attack the system.

        - A major part of security is about preventing possible attacks (theoretical attacks), which means that many security measures applied to a machine never get activated/triggered.

        - I don't understand why you are using vulgarisms in your posts. You could try to learn to resist the urge to use them, with time.
        Wow, so you're insisting on locking down something which is immensely useful for most users only because in theory it can be used to hack a system? Wow. What about other exceptionally good additional security measures like locking down /proc access, so that the user can see only his processes? All this security madness will lead to one thing, the user will start running lots of things via sudo by default and the net result will be decreased security. Oh, and don't get me started on the leaky X.org security model where all windows can have full access to other windows' input (mouse/keyboard/touchpad/etc.). Each time you enter your sudo/su password, everything running in your X session may intercept it. Idiots, so many idiots everywhere.
        Last edited by birdie; 04-21-2019, 11:32 AM.

        Comment


        • #44
          Seems like the best approach would be to lock it down by default, and make it accessible in a diagnostic boot mode, something between console only rescue mode and secured multiuser mode. I might play around with a runlevel to see how feasible a package or script to deploy such a mode would be.

          Comment


          • #45
            Originally posted by szymon_g View Post
            btw, is there any way to restrict ability of a 'normal' user to see the processes owned by root/others? I know Grsecurity used to offer it few years ago, I wonder if I can have something similar now without that patch
            Code:
            mount -o remount /proc -o hidepid=2
            see man 5 proc

            Comment


            • #46
              Originally posted by birdie View Post
              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.
              For a moment imagine that there are people out there that are not running just single user systems and rethink how all that you just wrote are completely void.

              Comment


              • #47
                Originally posted by F.Ultra View Post
                For a moment imagine that there are people out there that are not running just single user systems and rethink how all that you just wrote are completely void.
                For a moment imagine that those people should absolutely not be the default.

                Comment


                • #48
                  Originally posted by F.Ultra View Post
                  AKA there are more, VB was just one example.
                  There are "potentially" more, which I don't care about. If there were more they'd give more examples.

                  Comment


                  • #49
                    Originally posted by Weasel View Post
                    For a moment imagine that those people should absolutely not be the default.
                    Linux is probably on a gazillion to one ratio between servers and single user desktops.

                    Comment


                    • #50
                      "All this security madness will lead to one thing, the user will start running lots of things via sudo by default and the net result will be decreased security."
                      This is a good point. Security vs. usability is a constant battle. If a distro does turn on CONFIG_SECURITY_DMESG_RESTRICT, users could restore the previous functionality via the sysctl.

                      Code:
                      mkdir -p /etc/sysctl.d
                      tee -a /etc/sysctl.d/90-security.conf<<<'kernel.dmesg_restrict = 0'
                      sysctl -p /etc/sysctl.d/90-security.conf
                      For completeness on the VirtualBox issue, it was fixed in the April 2017 CPU, and issued CVE-2017-3513. As for other examples, I don't have any off the top of my head. Previous work such as the "kptr_restrict for hiding kernel pointers" patch shows that this has been something people have been thinking about for a while. If one wished to find more examples, research on what prompted that patch would probably lead to more instances of leaked addresses. However, regardless of lack of previous examples, it is always possible that an address leak could be added to the kernel or an out of tree module unintentionally. In which case, an author leaking addresses may avoid using %pK, and therefore still leak. Having CONFIG_SECURITY_DMESG_RESTRICT set thus prevents usage regardless of the way it was written to the kernel logs.

                      Comment

                      Working...
                      X