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

Re: Adding users to plugdev dynamically

On Sun, Dec 19, 2004 at 12:26:43PM +0000, Rob Bradford wrote:

 > * Our users are bound to forget to add any new user they create to
 > this group (among others including audio) leading to an increase in
 > bug reports and frustrated users. This could be resolved by making
 > the g-v-m warn that the user is not in the plugdev group when it is
 > run (if it does not already do this).

 Hold your horses back... people are getting way too eager to hardcode
 this "plugdev" thing.

 Care to define "our users" for me please?  This "are bound to" tickles
 me a tad.

 "plugdev" is the default group assigned to "pmount", which is mode
 4750.  This is the "security" device used to ensure that only the
 correct user can mount and unmount devices.  This can be overridden,
 though (dpkg-statoverride).  So the right thing to do is to check if
 the user has exec permissions for pmount.

 > * In a network environment where the authentication and group
 > membership is specified by NIS/ldap/etc, this could cause issues if
 > there are certain machines where the removal media might be private,
 > or the system acts as an individual's workstation but is also
 > accessible remotely.

 Which is actually the case where this matters.  The case of people at
 home is rather irrelevant, since the kind of security and access
 control in that scenario is totally different.  In that case the user
 plugs a camera and he wants to have access to the data stored on it,
 period, it's unlikely that there are malicious users wishing to access
 the same data.

 What you actually want to test for is presence at the console, which
 probably means defining some X displays and ttys as "the console".  You
 can implement this by looking at the logged-in information.  What I'm
 getting convinced of is that pmount's policy needs to be configurable,
 probably in a PAM-ish sort of way.

 The problem with the plugdev group solution is that once you are in the
 correct group, you can arrange to have permanent membership to this
 group, which, in the scenario that's relevant, is a big deal.

 The solution used by SuSE is to assign ownership of the device to the
 user.  AFAIUI there's a kernel patch involved in this.  This solution
 has its own share of problems.  With the pmount method you don't need
 access to the device to mount it (/dev/cdrom with mode 0600 and owned
 by root can still be mounted by a user; screws up DVD playing though)
 yet you can't fool around with the hardware.  SuSE does this with the
 audio devices, CD* devices and the like.  Stops pranks like logging in
 over the network and farting thru the loudspeakers -- which is probably
 a big deal for them.

 > In particular a problem could arise where a malicous user logs into
 > the system remotely, via ssh, and starts a process that monitors for
 > the insertion of a usb keystick, and upon insertion mounts and gains
 > control of this stick. This would either be a DoS and prevent the
 > user logged in directly at the workstation from using and mounting
 > it. Or worse this could lead to information leakage and if that
 > device is being used to store an ssh/rootplug/gpg key then there is a
 > real security risk.

 You have to understand that pam_group doesn't prevent this.

 > All these problems would be avoided if the pam configuration files
 > for say gdm/xdm/console logins automatically added the user to the
 > group.

 No, they wouldn't.

 When I pointed someone to pam_group I did say that you have to watch
 out for the lack of security involved with pam_group.  I mentioned that
 as a solution because it's one that's easy and fast to implement (which
 is probably what a home user wants), not because it's secure.


Reply to: