On Thu, Oct 28, 2004 at 08:46:18PM +0200, Julien BLACHE wrote: > >> I plan to have SANE built with resmgr support for Etch, and I hope > >> other applications will support resmgr too. It can make life a lot > >> easier, and changes to the code are really minimal. > > > > It is, however, a security hole; it's functionally equivalent to > > pam_console (which we declined to ship in the past) and has the same > > It's a bit better than pam_console, however, which has a lot of > issues. > > I uploaded to experimental to get some feedback on the possible > security issues/implications; I'm still trying to determine whether > there are holes (read: bigger holes than those which can exist with > other solutions) or not. > > Could you point out the security issues you see in resmgr ? The primary one is the same as pam_console: once you have an fd open, you can keep it open for as long as you like. So all the fancy restrictions on when you can open a device don't actually do anything; if you can open it at any time, you have effective access, reducing it to the same level of security as group permissions. (Doing something about this would require either a genuine userspace *proxy*, or kernel support; there's a few proposals floating around about how pam_console could have done it right). While it may make sense on some public terminals or demonstration systems, you do not want it on hosts where device security is important. [Also, it's a liability to have a process running as root which opens devices and then hands fds over to non-root processes; it could form part of a privilege escalation attack. So you don't want it running without a good reason]. > I note that SuSE ships resmgr and has a couple of resmgr-enabled > applications. Of course, RedHat ships pam_console, so that's not a > point (and they're having a whole lot of problems with it, again). Yes, they just don't care. Secure-by-default isn't really a priority for them. If you run a server on suse then resmgr is one of those things you have to go through and rip out, like pam_console on redhat. > - resmgrd isn't installed by default, you need to explicitly install > it (no dependencies, only a Recommends that could be downgraded to > a Suggests to avoid side-effects with some frontends to apt); I'd say that's the really important one; we need to keep it that way. > - resmgrd won't be started until configured (no default config > is shipped in the package, only an example config file); And that's probably a good idea too (along with documentation that clearly states what it does and does *not* do). > > (Why somebody bothered to implement resmgr instead of simply enhancing > > pam_console is beyond me; probably NIH) > > If you haven't already, you might want to read > <http://rechner.lst.de/~okir/resmgr/description.html> Yeah, they gave up on the puzzle of how to fix pam_console without really trying. It's not as hard as they made it look; mostly you just have to add hotplug support, and have pam_console itself record the current user in a file or process someplace. Quite ironically, the solutions to the problems they cite for pam_console are exactly the same as the solutions they implemented for resmgr. Hence I figure it was probably NIH. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- |
Attachment:
signature.asc
Description: Digital signature