Giving power to the user in front of the screen
Posted by mcortese on Wed 14 Dec 2005 at 14:32
Modern desktop computers running Linux have a sort of double personality that they do not usually share with Windows-based PCs. On the one hand, they are used as single-user workstations where the operator is granted full access to the machine resources, and on the other hand they are also real servers.
Of course there is no reason why a network user located far away should have free access to our machine's audio device or, much worse, to the modem configuration.
With Linux rising popularity in the desktop market, we need a way to distinguish the "user in front of the screen" (better named desktop user) from the "user from far away" (better named remote user), and grant them different rights. This is how I solved this problem for my local network of double souled computers.
A group-based solution
To begin with, all services that need to be accessed selectively, need to be associated to a group, and the file permissions should be set accordingly. For example, if we wnat that "right people" is able to play music, change the volume, and grab their talking into the microphone, the sound device should be readable and writeable by group audio and not by anyone else. Like that:
crw-rw---- 1 root audio 116, 33 9-dic 22:42 /dev/snd/timer
You can use the following groups for a number of commonly available services (feel free to add your own items to this intentionally incomplete list):
- audio for the audio device(s), the mixer and the RTC
- video for the framebuffer device, and all the hardware acceleration modules
- cdrom for CDs and DVDs (remember to set write permission to enable burning)
- floppy for all other removable media, like flash drives...
- dialout for serial I/O
- dip for PPP scripts and configuration files
- scanner for the scanner
(Previously we covered the Debian groups here.)
Please note that if you are using udev, you may need to change the file /etc/udev/permissions.rules to have the new settings applied by default.The next step, in line with the best practice of secure computing i.e. deny power by default, is to be sure that the above mentioned groups have no permanent members. Edit /etc/group and check that no regular users are listed in the last field of the groups you are interested in.
Members on the fly
At this point it should be clear that the problem now is no more a matter of "who can access that file/service", but rather of "who is member of that group". The trick is to make a user a member of one or more groups "on the fly", based on the login method.
Surprisingly enough, there is a PAM module that does exactly this: pam_group. A line like:
auth optional pam_group.soshould be added to all the relevant files in /etc/pam.d/, for example to /etc/pam.d/gdm (assuming you are using GDM for the graphical login) and /etc/pam.d/login.
The pam_group module has its own configuration file (/etc/security/group.conf) that needs to be set up properly. The syntax is a little over-complicated, but it allows for the most flexible configuration.
The following example shows how to give membership to the audio, video, cdrom, floppy, and dip groups to the users that authenticate themselves via GDM:
gdm; *; *; Al0000-2400; audio, video, cdrom, floppy
How much secure is it?
It should be noted that the method depicted above is a good solution, and at least prevents remote users from accidentally shoot full-volume music out of the loudspeakers in a far and possibly crowded site. But if you are talking about security in terms of preventing a malicious, yet regular user to access the resources when he should not, then this method is not secure.
Imagine a desktop user (logged in via GDM, and hence with full membership to audio group) doing the following:
$ id uid=1000(mfc) gid=1000(mfc) groups=24(cdrom),29(audio), 44(video),1000(mfc) $ cp `which mpg123` . $ chown .audio mpg123 $ chmod g+s mpg123 $ ls -l mpg123 -rwxr-sr-x 1 mfc audio 38K Dec 10 00:48 mpg123What we have here is a program that, when executed, gets the rights of group audio no matter what the rights of the caller are:
$ su mfc Password: $ id uid=1000(mfc) gid=1000(mfc) groups=1000(mfc) $ ./mpg123 my_preferred_song.mp3
Nevertheless, this system still provide trivial protection against users who have never desktop access to your machine.
[ Send Message | View Steve's Scratchpad | View Weblogs ]
I updated the text to fix the typo you spotted.
[ Parent | Reply to this comment ]
It probably makes it a bit more user-hostile though if you do that.
PJ
[ Parent | Reply to this comment ]
"
Important note for Debian: The permission to execute pmount is
restricted to members of the system group plugdev. Please add all desk-
top users who shall be able to use pmount to this group by executing
adduser user plugdev
"
Since the desktop user was authenticated from a remote LDAP server there was no way to include his username in the plugdev group, in fact "a priori" his username was not known at all.
Following the instructions of this article and putting the suid bit to pmount command everything works fairy well.
Thanks Matteo!
[ Parent | Reply to this comment ]
this way you never wonder why editing
/etc/security/group.conf doesn't do anything,
it's so easy to forget adding pam_group.so to
every relevant pam.d file.
[ Parent | Reply to this comment ]
Good suggestion.
In fact, I've always judged it redundant to have to modify two conf files whan you want to add an application to those handled by pam_group.
[ Parent | Reply to this comment ]
Thank you for the great write up.
I'm trying to do something similar in the recent Etch RCs but not having much luck.
It looks like since Oct 06 they are using HAL/dbus/udev instead of pmount directly to give access to things like usb pendrives or usb Hard drives now. (in KDE/Gnome) pam_group doesn't put the dynamic group membership in a "location" where its read by dbus/hal.
Have you had any luck with adapting your configuration to what will be the new stable?
Relevant links:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=377689
http://www.mail-archive.com/debian-devel@lists.debian.org/msg2407 93.html
Thank!
David.
[ Parent | Reply to this comment ]
I think Jean-Christophe Dubacq put it right (quoted from bug #377689):
this is because dbus is a system-wide daemon and has no access to "the user in the session" (due to its asynchronous nature, it is not inheriting anything from the process that issues the request)
I still have to understand if dbus is sensible to changes in the /etc/group file occurred after it was started. If so, a workaround would be to add the current user to the plugdev group not only via pam_group, but also via an explicit
# adduser $WHOEVER plugdevat login and then remove it at logout.
As soon as I re-gain access to my Debian box, I'll try some experiments.
[ Parent | Reply to this comment ]
I'd love to hear anything you come up with! If you need a beta tester... ;)
[ Parent | Reply to this comment ]
[ Send Message ]
Regarding the setgid executable in the user directory, just mount /home (and /tmp of course) with the nosuid option.
--
Debian GNU/Linux on an IBM Thinkpad T43p
[ Parent | Reply to this comment ]