Summary: | Incorrect permissions of /dev/mem could lead to retreival of passwords | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Roel Brook <Rainmaker526> |
Component: | [OLD] Core system | Assignee: | Gentoo Linux bug wranglers <bug-wranglers> |
Status: | RESOLVED INVALID | ||
Severity: | normal | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Roel Brook
2004-05-09 16:37:48 UTC
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. |