When playing around with the files in /dev/mem, I found the following: doing cat /dev/mem > foo leads to the contents of the memory being dumped to the file. Nothing new there. Now forgive me for being paranoid, but searching through that text-file, I found the passwords of all the currently logged in users in cleartext. It seems to come up while searching for system-auth or /dev/vc/1 When checking permissions on /dev/mem they read crw-r----. This means that basicly any user in the root group could use this to retreive passwords. Even root shouldn't be able to VIEW the password (only change it). Please forgive me if you feel I'm to paranoid Reproducible: Always Steps to Reproduce: 1. Reboot system (I think the passwords could be overwritten while using memory-intensive programs) 2. login as root 3. execute /dev/mem > foo 4. Open foo in nano 5. Search for your root password. On my system, this gave me 5 results Actual Results: It found my root password Expected Results: Returned [12345] not found
root owns you. If you don't trust root, you shouldn't log into the machine.
Sorry for re-opening, but what about the read permissions for root GROUP? The root group users should NOT be able to read other users passwords
Please close this bug, as it really doesn't apply as a "real" bug. If you think this is a real bug, feel free to write in to the lkml and include devfs/udev in the subject line (depending on which one you use) as it's probably something that comes that way from kernel.org. In Closing: If you have problems trusting your users, don't give them access!
closed
This exactly what grsecurity is ideal for. You can mark /dev/mem /dev/kmem /dev/kcore all as read-only or hide them all together from getdents() Here is the output of ls -l /dev/{k,}mem from a slackware box. crw-r----- 1 root kmem 1, 2 Jul 18 1994 /dev/kmem crw-r----- 1 root kmem 1, 1 Jul 18 1994 /dev/mem It's still g+r as we can see but it has it's own group assigned. I can't recall what it is off the top of my head but some silly program needs +r on /dev/mem. But really grsec is the way to go if you care about protecting from such things.
