Announcement

Collapse
No announcement yet.

Linux 5.1 Picking Up Option To Lockdown All But Internal USB Devices

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

  • Linux 5.1 Picking Up Option To Lockdown All But Internal USB Devices

    Phoronix: Linux 5.1 Picking Up Option To Lockdown All But Internal USB Devices

    A change for Google's Chrome OS is working its way into the upstream Linux 5.1 codebase that adds a new mode to the kernel's USB authorization mechanism. This opt-in change will allow users/administrators to only authorize internal USB devices by default...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    I wonder how it discriminates between an internal vs external device? After all, a motherboard USB header can be connected to an internal device (dvd drive for example) or to a panel of external USB ports on the front or rear of the chassis. How does it know?

    Comment


    • #3
      Originally posted by torsionbar28 View Post
      I wonder how it discriminates between an internal vs external device? After all, a motherboard USB header can be connected to an internal device (dvd drive for example) or to a panel of external USB ports on the front or rear of the chassis. How does it know?
      I'm wondering the same thing.

      Comment


      • #4
        Pretty sure that by "internal" they mean "soldered down".

        For example, in chromebooks the trackpad and camera are usually USB devices with no physically disconnectable port. These would be authorized. Anything with a port that can be disconnected without desoldering counts as external.

        The chromebook keyboard, OTOH, uses an obscure and spooky non-usb interface that goes through the power control ("EC") chip.

        Comment


        • #5
          I don't understand why this is necessary when we have Usbguard (user-space, yes, but works)

          Comment


          • #6
            Originally posted by q2dg View Post
            I don't understand why this is necessary when we have Usbguard (user-space, yes, but works)
            It's explained in the linked commit, "On Chrome OS we want to use USBguard to potentially limit access to USB devices based on policy. We however to do not want to wait for userspace to come up before initializing fixed USB devices to not regress our boot times."
            Michael Larabel
            https://www.michaellarabel.com/

            Comment


            • #7
              Is there some unified Linux 5.1 branch now, or development happens in all kind of different branches, and only later is merged into Linus' branch when he prepares it for next release (like it happens now for 5.0)?

              Comment


              • #8
                Originally posted by shmerl View Post
                Is there some unified Linux 5.1 branch now, or development happens in all kind of different branches, and only later is merged into Linus' branch when he prepares it for next release (like it happens now for 5.0)?
                There is linux-next repo though that is never necessarily accurate/guaranteed what's going into the N+1 release or not.

                I personally monitor all of the -next branches for seeing what's being queued for going into the next release.
                Michael Larabel
                https://www.michaellarabel.com/

                Comment


                • #9
                  Originally posted by WesternSemiconductor View Post
                  Pretty sure that by "internal" they mean "soldered down".

                  For example, in chromebooks the trackpad and camera are usually USB devices with no physically disconnectable port. These would be authorized. Anything with a port that can be disconnected without desoldering counts as external.
                  There's no way to identify that though. To the computer, it doesn't matter if the component is soldered down or plugged in through a port, it all looks the same.

                  Comment


                  • #10
                    Originally posted by Michael View Post

                    There is linux-next repo though that is never necessarily accurate/guaranteed what's going into the N+1 release or not.

                    I personally monitor all of the -next branches for seeing what's being queued for going into the next release.
                    I see, thanks. I was using 5.0-rc7 with some manual patches, but now they reverted bulk moves for amdgpu, so I'd probably stick to 5.0-rc7+ until 5.1 will surface.

                    Comment

                    Working...
                    X