pam_group (Was: ubuntu-xxx ....)

[Jerry Haltom]

I'd just like to add, as a user tasked with maintaining an office of
Windows systems, that this default behavior *is* a minus to replacing
those with Ubuntu.

Consider that the job of an admin isn't to choose the most
philosophically superior operating system for his deployment, but to
choose the one that will get the job done best. "Best" has a lot of
definitions. It is a balance between features, security, and hands-off
management and the benefits of the software development model. Remember,
every second an admin is spending doing something on one OS that they
wouldn't have to do on another counts against it. Every benefit derived
from doing those actions counts for it.

So we have to examine the benefits of using pam_group on this deployment
scenario: large numbers of desktops.

1. A policy  that "users who sit down and log in, can use the CD drive"
is the obvious function that a desktop user would expect.

2. The Real World benefits are fairly large. Adding 20,000 users (or
even 10) to every local cdrom group on every system is not practical.
The admin has to keep up with this. It is a task he has to do across
every desktop. Or he has to develop or deploy software to do it for him.
Either way, it wastes his time.

3. The Real World issues with this are not THAT BIG OF A DEAL. If users
are not supposed to be able to get access to the system remotely, then
that can be configured (disabling SSH, configuring SSH policies). Yes,
it isn't "perfect", but if you're going to tell me any large scale
desktop admin CARES that his users can access the CD drive remotely
(after going through the mostly hard actions to do it, setting a sgid
binary, etc) I wouldn't believe you. Sure, it's a hole. Is it a hole
that causes any sort of real damage if exploited? Is it a hole that
doesn't leave a trace *in 99% of circumstances*? No. If it was MS
wouldn't be doing it or you'd hear about people exploiting each other's
CD drives.

In this case the math is simple. The benefits of using pam_group are
high. The minuses to using it are low. The benefits to not using it are
low, the minuses to not using it are high.

If nothing else this seems like something I'd want configurable in some
sort of templatable policy. For desktops I would install with cdrom
readable by everybody, for servers I wouldn't.

The same goes for sound.

On Thu, 2005-03-31 at 12:38 -0800, Matt Zimmerman wrote:
> On Thu, Mar 31, 2005 at 10:16:05PM +0200, Timo Aaltonen wrote:
> 
> > >Why is it a problem to add these users to the necessary groups?  That is
> > >the simplest and most robust solution.
> > 
> > Not if you have >20000 users.
> 
> Surely with that number of users, you have tools to make changes like this
> automatically.
> 
> > Besides, isn't it a security problem to have all users in all those groups
> > that are desktop-specific? At least when ssh-connections are accepted...
> 
> What sort of security problem?  If the user should have these privileges
> according to your security policy, they should be granted to them.
> 
> > More "elegant" solution is to tell gdm to use pam_group (as I already told 
> > Adrian in a private mail):
> > 
> > -add this line in /etc/pam.d/gdm:
> > 
> > auth    optional        pam_group.so
> > 
> > -modify /etc/security/group.conf, for hoary-installation it could be 
> > something like this (looking at my laptop and the groups I'm on):
> > 
> > gdm;*;*;Al0000-2400;floppy,audio,cdrom,video,plugdev,scanner
> > 
> > now, only the local user has access to the devices etc. Neat and tidy, huh? 
> > ;)
> 
> It seems that way at first, but in fact the semantics are closer to "any
> user who has ever logged in locally has access to these devices".  Pitfalls
> like these are the reason why we don't "magically" grant permissions based
> on dynamic criteria.  If the user should have access to the devices, they
> should be granted, otherwise not.  The capability does not currently exist
> to revoke these permissions from users once they have been granted.
> 
> -- 
>  - mdz
> 
-- 
Jerry Haltom <wasabi at larvalstage.net>