policies for access to local resources
On Wed, 31 Mar 2004 14:15:00 -0500 (EST), Sam Hartman <hartmans@debian.org> 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
Reply to: