[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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"

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.



Reply to: