Originally posted by caligula
View Post
Ubuntu 20.10 Looking At Restricting Access To Kernel Logs With dmesg
Collapse
X
-
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 ;-)
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
-
-
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.
Comment
-
-
Originally posted by zyxxel View PostThere aren't any user-fixable parts there for a normal user.
Comment
-
-
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.
Comment
-
-
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.
Trying a different USB cable or thumb drive/joystick/etc. is perfectly user-fixable for a non-administrative user.
Comment
-
-
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.
Comment
-
-
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.
...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
-
-
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.
Comment
-
Comment