Ubuntu 20.10 Looking At Restricting Access To Kernel Logs With dmesg

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

  • ssokolow
    replied
    Originally posted by caligula View Post

    You can still use 'lsusb' or 'udevadm' to find out if the cable is ok and the device will appear. Modern desktop environments should notify the user user in case there are hardware issues. If it's a HID device, /dev/input file will appear. The high level apps should also auto-detect hot plugged devices. Imagine using some other OS like Mac or Windows, no sane person will try to read the kernel logs when troubleshooting the issue. The high level GUI interfaces are sufficient.
    First, I remember some distros not installing lsusb by default, which you'd need sudo permissions to remedy, and udevadm is something I wouldn't wish on my worst enemy. (I write blog posts about how to use it when I'm trying to gather the information I need to write new udev rules because, even with Google, the interface design is such a mess... Early versions of git, eat your heart out.)

    Second, tools like that won't distingush between "device is dead" (no message on insertion) and "device failed to initialize" (bad/too-long cable, usually).

    Third, modern desktop environments should inform users, but most don't in my experience, and I care about end-user experience, not "Let's fix this and then pass the buck. It's the DE's fault if the user experiences a regression, not ours." They should learn from the spirit of the kernel's userspace ABI stability and not be allowed to make a change like this unless they first get compensatory patches merged into all major DEs.

    Fourth, looking in /dev/input means I have to unplug the device again, then run ls -1 /dev/input > temp.txt, then plug it in and ls -1 /dev/input > temp2.txt; diff -u temp.txt temp2.txt; rm temp.txt temp2.txt. dmesg does that for me in a single command. (I don't know about your distro, but it's a crapshoot whether *buntu will put an alias in the by-id and by-path folders.)

    Leave a comment:


  • thogs19
    replied
    Couldn't there be at least a filter where only the INFO would appear when dmesg was ran by unprivileged user?
    Since my desktop is very minimal I want to access dmesg everytime I plug-in a usb to assure myself what's the name of the new usb-storage device and not gonna touch the wrong one for let's say if I want to reformat the new device.

    Leave a comment:


  • caligula
    replied
    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.
    You can still use 'lsusb' or 'udevadm' to find out if the cable is ok and the device will appear. Modern desktop environments should notify the user user in case there are hardware issues. If it's a HID device, /dev/input file will appear. The high level apps should also auto-detect hot plugged devices. Imagine using some other OS like Mac or Windows, no sane person will try to read the kernel logs when troubleshooting the issue. The high level GUI interfaces are sufficient.

    Leave a comment:


  • zyxxel
    replied
    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.

    Leave a comment:


  • ssokolow
    replied
    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.

    Leave a comment:


  • zyxxel
    replied
    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.

    Leave a comment:


  • ssokolow
    replied
    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.

    Leave a comment:


  • zyxxel
    replied
    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.

    Leave a comment:


  • royce
    replied
    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.

    Leave a comment:


  • ssokolow
    replied
    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.

    Leave a comment:

Working...
X