On Wed, 31 Mar 2004 14:15:00 -0500 (EST), Sam Hartman <[EMAIL PROTECTED]> said: > The proposal in bug #166718 and the bugs merged with it is for the > initial user to be added to some set of groups. Karl does not like > this proposal because it only solves the problem for the initial > user. That's great until you actually start to take advantage of the > fact your Debian system is multi-user. > > Another proposal is to use paM_group to manage these groups. IF > someone is logging in on /dev/tty[0-9] or :0 or :0.0 or one of the > other console devices, given them audio, cdrom and floppy. This isn't > really all that desirable either because it allows any console user > to permanently gain that group. In particular, they can create a > setgid executable belonging to that group. > > The solution some Solaris environments I'm familiar with use to this > problem is to chown the appropriate devices to the console user. That > prevents the console user from giving away privileges. I'm not sure > it's compatible with the FHS, and I'd certainly want buy-in from the > rest of Debian before doing that. Also, I don't believe we currently > have an implementation of something to do that chowning in > Debian--presumably it would be a PAM module. I don't have time to > write code to solve this and I don't think Karl does either. > > The Redhat pam_console module does seem to do roughly what we want . > IN the past people have objected significantly to adding this module > to Debian for security track record reasons. I don't know how valid > these objections are.
I think the pam_console idea is the best solution available for the widest audience. However, it would probably be a good idea to give the people who have security concerns an easy way of avoiding this solution when building large sets of machines. One solution for people with security concerns [I've not looked at pam close enough to see how doable this is] might be to create a "hardened" package which satisfies the pam_console dependency, and conflicts with the real pam_console, and in some way addresses the config file issue, and provides no pam functionality whatsoever (so it's obvious it can't do the ownership munging). This could then be made a part of the "harden" task... We're already doing things which I consider to have a much higher security risk. (For example, we are building kde with a dependency on fam which requires rpc, and last time I checked there was no easy way to lock rpc down so that it would be as secure as pam_console's ownership changing on device files). One other note: some people might want to use the "all home users are in the device specific groups" mechanism. For example, pam_console doesn't do the right thing for a multiple-console machine (those are rare, but not impossible with a bit of kernel hacking, and this is just an example). For example, pam_console doesn't do the right thing for a network of home machines where someone wants to remote in and access the sound system... I didn't see anything in your proposal to get rid of support for device groups, but I wanted to mention that device groups would still have some value to some people. And I agree with Wichert that cleanup (for example, at boot time) would be important with pam_console. Thanks, -- Raul
