Ubuntu 20.10 Looking At Restricting Access To Kernel Logs With dmesg

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • rene
    Senior Member
    • Jul 2015
    • 1507

    #21
    Originally posted by caligula View Post

    Pro user, lmao. How about: alias dmesg='sudo dmesg'
    How about not hundreds of aliases and stuff just works? To everyone falling for this, this is a prime example of: Security through obscurity. If this would be done by Microsoft on Windows we would laugh our ass of ;-)
    Last edited by rene; 18 June 2020, 08:14 AM.

    Comment

    • zyxxel
      Senior Member
      • Mar 2020
      • 159

      #22
      Originally posted by rene View Post

      How about not hundreds of aliases and stuff just works? To everyone falling for this, this is a prime example of: Security through obscurity. If this would be done by Microsoft on Windows we would laugh our ass of ;-)
      No. If I run as a normal user, Windows does interact to verify when additional permissions are needed.

      There is really no reason why a normal user should be able to view the dmesg output. There aren't any user-fixable parts there for a normal user. And a pro user should already be pro enough to be very comfortable with the sudo concept to escalate the access rights when needed.

      Comment

      • rene
        Senior Member
        • Jul 2015
        • 1507

        #23
        Originally posted by zyxxel View Post

        No. If I run as a normal user, Windows does interact to verify when additional permissions are needed.

        There is really no reason why a normal user should be able to view the dmesg output. There aren't any user-fixable parts there for a normal user. And a pro user should already be pro enough to be very comfortable with the sudo concept to escalate the access rights when needed.
        how many users do people have on their local Linux workstations? And how many users are usually working on servers? There, that certainly answers the questions. ;-)

        Comment

        • ssokolow
          Senior Member
          • Nov 2013
          • 5132

          #24
          Originally posted by zyxxel View Post
          There aren't any user-fixable parts there for a normal user.
          Not quite correct. dmesg is a good way to tell what level of the stack is responsible for a USB hotplug not working as expected. (eg. You can use it to tell the difference between a dead device or "charging-only" USB cable, a shoddy USB cable, and a device that initialized correctly but didn't trigger the higher-level "on hotplug" handlers for some reason... as well as to easily identify the name of the /dev node to feed to something like udisks which allows unprivileged user-initiated mount/unmount operations on removable devices.

          Comment

          • royce
            Senior Member
            • Aug 2018
            • 661

            #25
            Originally posted by rene View Post
            I tried this, it was super annoying when you are a pro user / developer.
            It would be one thing of many you need to sudo for. It's no big deal.

            Comment

            • zyxxel
              Senior Member
              • Mar 2020
              • 159

              #26
              Originally posted by ssokolow View Post

              Not quite correct. dmesg is a good way to tell what level of the stack is responsible for a USB hotplug not working as expected. (eg. You can use it to tell the difference between a dead device or "charging-only" USB cable, a shoddy USB cable, and a device that initialized correctly but didn't trigger the higher-level "on hotplug" handlers for some reason... as well as to easily identify the name of the /dev node to feed to something like udisks which allows unprivileged user-initiated mount/unmount operations on removable devices.
              If you are the machine owner, then I'm pretty sure you have access to sudo dmesg, and can supply the password.

              Comment

              • ssokolow
                Senior Member
                • Nov 2013
                • 5132

                #27
                Originally posted by zyxxel View Post

                If you are the machine owner, then I'm pretty sure you have access to sudo dmesg, and can supply the password.
                You're moving the goalposts. You said "There is really no reason why a normal user should be able to view the dmesg output. There aren't any user-fixable parts there for a normal user."

                Trying a different USB cable or thumb drive/joystick/etc. is perfectly user-fixable for a non-administrative user.

                Comment

                • zyxxel
                  Senior Member
                  • Mar 2020
                  • 159

                  #28
                  Originally posted by ssokolow View Post

                  You're moving the goalposts. You said "There is really no reason why a normal user should be able to view the dmesg output. There aren't any user-fixable parts there for a normal user."

                  Trying a different USB cable or thumb drive/joystick/etc. is perfectly user-fixable for a non-administrative user.
                  No, it's a question of what value you put into "normal user". Whatever they do, they will not block machine owners from accessing their machine. So that part really is outside the scope of the debate. But if you have a school computer where 500 students have accounts, these students are also "normal users". But have no reason to be allowed to read kernel log output.

                  Comment

                  • ssokolow
                    Senior Member
                    • Nov 2013
                    • 5132

                    #29
                    Originally posted by zyxxel View Post

                    No, it's a question of what value you put into "normal user". Whatever they do, they will not block machine owners from accessing their machine. So that part really is outside the scope of the debate. But if you have a school computer where 500 students have accounts, these students are also "normal users". But have no reason to be allowed to read kernel log output.
                    I think we're done discussing this. That's like the schools I heard about shortly after I graduated high school where they'd fill their USB ports with hot glue and require students to take their work home on floppy disk, rather than implementing proper protection against whatever vulnerability they thought USB would bring to bypassing their desktop lockdown suite.

                    ...or, conversely, the "Don't do that. Copy-paste URLs instead" answer to the Firejail FAQ entry on the topic making a sandboxed browser work as a handler for URLs in other applications.

                    Comment

                    • zyxxel
                      Senior Member
                      • Mar 2020
                      • 159

                      #30
                      Originally posted by ssokolow View Post

                      I think we're done discussing this. That's like the schools I heard about shortly after I graduated high school where they'd fill their USB ports with hot glue and require students to take their work home on floppy disk, rather than implementing proper protection against whatever vulnerability they thought USB would bring to bypassing their desktop lockdown suite.

                      ...or, conversely, the "Don't do that. Copy-paste URLs instead" answer to the Firejail FAQ entry on the topic making a sandboxed browser work as a handler for URLs in other applications.
                      USB doesn't stop working because you need to write sudo to access dmesg output. And in a school, it isn't the students who should play along with any alternative drivers if they have too interesting USB devices they want to try to connect.

                      Comment

                      Working...
                      X