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.
Marcelo
Reply to: