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.so
should 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 mpg123
What 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.

 

 


Posted by spiney (128.131.xx.xx) on Wed 14 Dec 2005 at 14:52
[ Send Message ]
There's a typo, in the pam configuration it should be pam_group.so, not .co

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 ]

Posted by Steve (82.41.xx.xx) on Wed 14 Dec 2005 at 15:15
[ Send Message | View Steve's Scratchpad | View Weblogs ]

I updated the text to fix the typo you spotted.

Steve

[ Parent | Reply to this comment ]

Posted by Anonymous (61.11.xx.xx) on Thu 15 Dec 2005 at 03:42
Seems to me the problem of remote user vs desktop user really should be addressed by the system itself by default. Ie pam_group.so should be there with sensible defaults already.

It probably makes it a bit more user-hostile though if you do that.

PJ

[ Parent | Reply to this comment ]

Posted by Anonymous (157.138.xx.xx) on Wed 22 Feb 2006 at 10:19
I had this simple problem: the "desktop user" was authenticated from a remote LDAP server. Using the module pam_mkhomedir he could "on the fly" have his local home directory created and have access to the local and network resources like printers and so on. But he could not see his removable devices like a usb pen drive because, as the pmount man page quotes:

"
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 ]

Posted by Anonymous (84.133.xx.xx) on Fri 17 Mar 2006 at 20:26
Put pam_group.so into /etc/pam.d/common-auth

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 ]

Posted by mcortese (82.50.xx.xx) on Sat 18 Mar 2006 at 01:47
[ Send Message | View Weblogs ]

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 ]

Posted by ehle (65.91.xx.xx) on Wed 22 Nov 2006 at 17:55
[ Send Message ]
Matteo,

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 ]

Posted by mcortese (213.70.xx.xx) on Fri 24 Nov 2006 at 18:47
[ Send Message | View Weblogs ]

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 plugdev
at 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 ]

Posted by ehle (65.91.xx.xx) on Sun 26 Nov 2006 at 04:16
[ Send Message ]
Thanks for the quick reply Matteo.

I'd love to hear anything you come up with! If you need a beta tester... ;)

[ Parent | Reply to this comment ]

Sign In

Username:

Password:

[Register|Advanced]

 

Flattr

 

Current Poll

Which init system are you using in Debian?






( 1023 votes ~ 6 comments )

 

 

Related Links