Slashdot Mirror

← Back to Stories (view on slashdot.org)

Chrome OS To Block USB Access While the Screen is Locked (zdnet.com)

Posted by msmash on from the good-thinking dept.

Google will add a new security feature to Chrome OS, the company's web-based operating system that powers its Chromebooks devices, it announced this week. From a report: The new feature, named USBGuard, will block access to the USB port access while the device's screen is locked. According to a Chrome OS source code commit spotted by Chrome Story earlier this week, the new feature is currently available in Chrome OS Canary builds and is expected to land in the stable branch of Chrome OS soon. Once this happens, users can enable it by modifying the following Chrome OS flag: chrome://flags/#enable-usbguard . The way this security feature is meant to work is by preventing the operating system from reading or executing any code when a USB-based device is plugged in, and the screen is locked.

3 of 91 comments (clear)

  1. Re:Macs had this for years by war4peace · · Score: 3, Interesting

    So if you have a locked screen and the keyboard stops functioning, plugging a new one in the USB port will not work?

    --
    ...gis sdrawkcab (usually not responding to ACs; don't bother posting as AC)
  2. Windows XP by darkain · · Score: 4, Interesting

    Microsoft already had this in the initial release of Windows XP a long ass time ago. They removed it with the very first SP. Why? Because if there are ANY keyboard issues, you cannot add another one at all. Windows XP Pre-SP USB device detection only happens AFTER login. You run the risk of literally be locked on the password screen with zero way to enter a password. Things may be different with attached keyboards and touch screens now, but I still like the idea of the safety net of being able to attach a keyboard during trouble shooting.

  3. Re:Why execute code on mount in the first place? by munch117 · · Score: 3, Interesting

    On the other hand, you do expect it to start executing file system driver code. So if you can trigger an exploitable vulnerability in a driver using a specially crafted file system image, that'll do the trick.

    Of course that applies to any driver, not just a file system driver. Perhaps the idea is that without a mass storage device it becomes harder to load an attack payload. Not a very convincing idea, I admit; there are certainly ways around that.