Re: gdm/Gnome/KDE and device permissions
[Gernot Salzer] what is the standard/canonical way of handling device permissions in Debian (etch in my case) on desktop PCs running a GUI? As you probably found out from the replies so far, there is no standard way. :( Here are some notes I wrote for Debian Edu. You might find it useful. Local device access --- The local user should have access to some of the local devices (sound, cdrom, etc) after logging in on the console or via kdm/gdm/xdm/etc, but not when logging in from remote via ssh. There are as far as I know two ways to make this happen. One way is to add the local user to the groups needed to access these devices, the other is to change the permissions on these devices to give access to the local user. The former is done using pam_group, while the latter is done using pam_devperm. Both have advantages and weaknesses. pam_group - By updating /etc/pam.d/common-auth and /etc/security/group.conf it is possible to add the logged in user to the grous needed (audio, floppy, cdrom, plugdev, video). In addition to getting access to the devices present during login, it also make sure hotplugged devices like USB sticks work (group membership in plugdev take care of this). The problem with this method is that every member of the groups in question can create a setgid program to gain access to the devices also when not logged into the machine. This will make it possible to record from the microphone, read and from the floppy, cdrom and usb stick, as well as play unwanted sound on other users computers. It is also possible to start long-running processes in the background to keep the access privileges to the devices in question. --- /etc/pam.d/common-auth.orig 2006-10-17 11:25:40.0 + +++ /etc/pam.d/common-auth 2006-10-17 11:25:29.0 + @@ -7,4 +7,5 @@ # (e.g., /etc/shadow, LDAP, Kerberos, etc.). The default is to use the # traditional Unix authentication mechanisms. # +auth optionalpam_group.so auth requiredpam_unix.so nullok_secure --- /etc/security/group.conf.orig 2006-10-17 11:27:32.0 + +++ /etc/security/group.conf2006-10-17 11:31:43.0 + @@ -55,6 +55,8 @@ #xsh; tty* ;*;Al0900-1800;floppy +*; tty*!ttyp*; *; Al-2400; audio,cdrom,floppy,plugdev,video +*; :0; *; Al-2400; audio,cdrom,floppy,plugdev,video # # End of group.conf file pam_devperm --- By installing libpam-devperm and updating /etc/pam.d/common-sessionn (and /etc/logindevperm to fix bug #393661 and get access to /dev/dsp), it is possible to modify the permissions of relevant devices when a user log in, and reset the permissions when the user log out. The user of the device is changed to the logged in user, and the mode is normally set to 0600 granting exclusive access. The problem with this method is that hotplug devices do not work, as they are not available when the user is logged in, and the device ownership is only modified when the user log in. Another problem is that the user can keep the access privileges for the devices after he log out by starting long-running processes in the background. --- /etc/pam.d/common-session.orig 2006-10-17 11:23:21.0 + +++ /etc/pam.d/common-session 2006-10-17 10:42:08.0 + @@ -7,3 +7,4 @@ # non-interactive). The default is pam_unix. # sessionrequiredpam_unix.so +sessionrequiredpam_devperm.so --- /etc/logindevperm.orig 2006-10-17 10:51:58.0 + +++ /etc/logindevperm 2006-10-17 10:53:08.0 + @@ -24,7 +24,7 @@ :0 0600 /dev/cdrecorder:/dev/cdrecorder1:/dev/cdrecorder2:/dev/cdrecorder3 :0 0600 /dev/dvd:/dev/dvd1:/dev/dvd2:/dev/dvd3 :0 0600 /dev/zip:/dev/zip1:/dev/zip2:/dev/zip3 -:0 0600 /dev/dsp0:/dev/dsp1:/dev/dsp2:/dev/dsp3 +:0 0600 /dev/dsp:/dev/dsp0:/dev/dsp1:/dev/dsp2:/dev/dsp3 :0 0600 /dev/fd0:/dev/fd0u1440:/dev/fd0h1440:/dev/fd0u720:/dev/fd0h720 :0 0600 /dev/fd1:/dev/fd1u1440:/dev/fd1h1440:/dev/fd1u720:/dev/fd1h720 :0 0600 /dev/sequencer:/dev/sequencer2:/dev/music Conclusion -- I recommend using the pam_group mechanism to get a working hotplug support, and recommend solving the setgid-issue by adding the nosuid mount flag to the partitions where users can add files (/home/, /tmp/, /dev/shm/, /var/lock/), and solving the problem with long-running processes by running some kind of idle-job killer to kill long-running processes. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gdm/Gnome/KDE and device permissions
Am Dienstag 17 Oktober 2006 13:50 schrieb Petter Reinholdtsen: By updating /etc/pam.d/common-auth and /etc/security/group.conf it is possible to add the logged in user to the grous needed (audio, floppy, cdrom, plugdev, video). In addition to getting access to the devices present during login, it also make sure hotplugged devices like USB sticks work (group membership in plugdev take care of this). Does that work when not using pmount but only hal to mount devices? Can the other side of d-bus messages be aware of such group memberships?: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=377689 Unless d-bus started to support this during the last month, setting plugdev via PAM will not always work (only when using pmount). Same probably goes for network-manager and its netdev group. HS pgpAPGGBeibyc.pgp Description: PGP signature
Re: gdm/Gnome/KDE and device permissions
[Hendrik Sattler] Does that work when not using pmount but only hal to mount devices? Can the other side of d-bus messages be aware of such group memberships?: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=377689 Thank you for the reference. It seem to me that this problem still exist in the KDE version we use. Unless d-bus started to support this during the last month, setting plugdev via PAM will not always work (only when using pmount). Same probably goes for network-manager and its netdev group. :( Friendly, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gdm/Gnome/KDE and device permissions
Qua, 2006-10-11 às 23:17 +0200, Tim Dijkstra escreveu: One problem is that a user can launch a daemon that keeps the device file open before she logs out Also I was referring to how pam_group works, but I find this way of handling permissions even more broken than pam_group. For example, what happens if somebody logs in on another VT? You know, sometimes I have the weird idea that interaction with these devices should be by some way proxied by the X server. The X server seems to be the only to knows who is in which VT at which time... it already have to proxy access to the video card, it isn't exactly insane to it proxy the access to other devices... For sound it's easy, X server would implement what is done by sound daemons today, but for other devices I don't know... But yeah, I consider it a weird idea... daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gdm/Gnome/KDE and device permissions
On Wed, 11 Oct 2006, Roland Mas wrote: Sam Morris, 2006-10-11 13:40:08 +0200 : I think HAL/PolicyTool/pam_foreground will eventually give us a (slow?) solution to problems like this, but it's some way off at the moment. Being able to add/revoke permissions with traditional security methods (i.e. group membership) requires kernel modification AFAIK. One could envision usage of POSIX ACLs. Very hackish, but some daemon could add an ACL entry to various files in /dev when a user logs in, or logs out, or time passes, or some device is plugged in, or whatever. No need for special groups. Of course, maintenance would probably be a nightmare, unless there's a way to share ACLs between files that I'm not aware of. /dev is a tmpfs and that filesystem supports ACL only in very recent kernel. IIRC it has been introduced in the (upcoming) 2.6.19. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gdm/Gnome/KDE and device permissions
On Wed, 11 Oct 2006 13:08:27 +0200, Gernot Salzer wrote: It seems that users have to be added to group audio in order to be able to access audio devices, group video to access video devices, cdrom to access cdrom, and so on. Or did I miss some setting during installation of etch? Having to add users to particular groups is not reasonable in a desktop setting. There, one would like to have the current user at the console (logged in via gdm or similar) to be the one with exclusive rights on local devices (fixed ones like audio and video as well as variable ones like external usb devices). I don't think it's possible to arrange for _exclusive_ access. Once a user has been granted access to a group it is not really possible to revoke the grant. Part of the problem can be solved by using libpam-permdev: it handles well fixed builtin devices like audio, video, cdrom, but fails with dynamic devices like usb sticks (the pam module is only active during login and therefore misses dynamic devices plugged in during the session). Moreover, since the module is not installed automatically with gdm, it doesn't seem to be the intended solution. There is also pam_group which seems to do the same thing--adds users to groups depending on their name, login method and time of day. For dynamic devices I haven't found a solution yet. Autodetection and automounting of e.g. usb sticks works with gnome, if there are entries in /etc/fstab. However, such entries are not reasonable since one doesn't know in advance which devices are plugged in in which order. Since groups are only set when a user logs in it's not possible to e.g., add the user to the plugdev group when they plug in a USB stick. You'd have to add them to plugdev when they log in. I think HAL/PolicyTool/pam_foreground will eventually give us a (slow?) solution to problems like this, but it's some way off at the moment. Being able to add/revoke permissions with traditional security methods (i.e. group membership) requires kernel modification AFAIK. -- Sam Morris http://robots.org.uk/ PGP key id 1024D/5EA01078 3412 EA18 1277 354B 991B C869 B219 7FDB 5EA0 1078 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gdm/Gnome/KDE and device permissions
Having to add users to particular groups is not reasonable in a desktop setting. There, one would like to have the current user at the console (logged in via gdm or similar) to be the one with exclusive rights on local devices (fixed ones like audio and video as well as variable ones like external usb devices). I don't think it's possible to arrange for _exclusive_ access. Once a user has been granted access to a group it is not really possible to revoke the grant. Don't mechanisms like libpam_devperm grant exclusive access? On login the ownership of the devices is set to the console user, and only the owner is granted rwx-rights. On logout ownership/permissions of the device revert to the old setting. There is also pam_group which seems to do the same thing--adds users to groups depending on their name, login method and time of day. Thanks for the hint, I will check it. Since groups are only set when a user logs in it's not possible to e.g., add the user to the plugdev group when they plug in a USB stick. You'd have to add them to plugdev when they log in. Couldn't a script triggered by udev set ownership/permissions to the current console user, like libpam_devperm does? I think HAL/PolicyTool/pam_foreground will eventually give us a (slow?) solution to problems like this, but it's some way off at the moment. Being able to add/revoke permissions with traditional security methods (i.e. group membership) requires kernel modification AFAIK. How do end-user Linux distributions that are supposed to work out of the box (like ubuntu, fedora, suse) solve this problem? World-rwx for all user devices? All users added to groups like audio, video, ...? Would it be possible to let all user devices (static or dynamic) be owned by group console with rwx rights, and add/remove the console user dynamically to/from this group on login/logout? This way it wouldn't matter whether e.g. the usb stick is plugged in before or after login. Wouldn't this solve the problem? Gernot -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gdm/Gnome/KDE and device permissions
On Wed, 11 Oct 2006 14:12:20 +0200
Gernot Salzer [EMAIL PROTECTED] wrote:
Don't mechanisms like libpam_devperm grant exclusive access?
On login the ownership of the devices is set to the console user,
and only the owner is granted rwx-rights. On logout
ownership/permissions of the device revert to the old setting.
First, there is no safe way to revoke privileges from a user. If a user
gets access to a certain group he/she can arrange ways to keep it,
even after being logged out (make a suid binary for example).
Second, several people can login at once on different VTs.
Since groups are only set when a user logs in it's not possible to e.g.,
add the user to the plugdev group when they plug in a USB stick. You'd
have to add them to plugdev when they log in.
Couldn't a script triggered by udev set ownership/permissions to
the current console user, like libpam_devperm does?
Why would you want to bring udev in the picture? If you think the scheme
used by pam_group (and similar) is secure enough for you, you can also grant
access to the plugdev, netdev and powerdev groups. Note that access control
is not hard coded to plugdev in dbus, you can edit the files in /etc/udev
to have more relaxed access control. Oh, on debian you also need to change
the permissions of p{u,}mount
How do end-user Linux distributions that are supposed to work out of the box
(like ubuntu, fedora, suse) solve this problem? World-rwx for all
user devices? All users added to groups like audio, video, ...?
Afaik, fedora has pam_console or something like that does something like
you suggest; give privileges to all users that log in at the console.
Also dbus has some support for this, but this isn't compiled in the
debian version, because of the caveats I outlined above.
Would it be possible to let all user devices (static or dynamic) be
owned by group console with rwx rights, and add/remove the console
user dynamically to/from this group on login/logout? This way
it wouldn't matter whether e.g. the usb stick is plugged in before
or after login.
Wouldn't this solve the problem?
As I said, no, it would not solve the problem safely for true multi-user
environments. FWIW, there has been some discussion and ideas floating
around on the HAL and DBus lists. The current consensus is that we need
a secure way for dbus/hal to know what is the current active virtual
terminal and how owns it. For mulit-head systems we need a way to
specify that certain devices (think usb ports) belong to a certain
display.
Nobody has had time to implement it yet however.
grts Tim
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gdm/Gnome/KDE and device permissions
First, there is no safe way to revoke privileges from a user. If a user
gets access to a certain group he/she can arrange ways to keep it,
even after being logged out (make a suid binary for example).
I admit that I don't know much about the internals of Unix/Linux.
So, if upon login of user foo ownership/permissions of /dev/audio are set to
crw--- 1 foo audio 14, 4 2006-09-22 13:25 /dev/audio
and after logout of foo and login of bar to
crw--- 1 bar audio 14, 4 2006-09-22 13:25 /dev/audio
foo might still be able to access /dev/audio ?
Second, several people can login at once on different VTs.
True, the general case is much more involved.
However, considering that the majority of desktops is single-headed,
it would be most useful to be able to install a package that sets up
the computer for this special case
such that people can work under gnome/kde like they are used to from
windows or mac-os. This includes to be able to access devices easily,
but without being pried upon by curious (but otherwise friendly and
non-hacker) remote users.
Why would you want to bring udev in the picture? If you think the scheme
used by pam_group (and similar) is secure enough for you, you can also grant
access to the plugdev, netdev and powerdev groups.
I don't want to grant access to groups but rather want to mimic
the behaviour of libpam-permdev that changes ownership/permissions
of the device to grant only access to the console user.
Maybe udev is the wrong term; with udev I mean the part of the
system that creates devices dynamically and thus knows when and
at which device e.g. a usb stick was plugged in, and can initiate
the action of changing the ownership/permissions.
I found a partial solution somewhere on the web working like that.
Note that access control
is not hard coded to plugdev in dbus, you can edit the files in /etc/udev
to have more relaxed access control. Oh, on debian you also need to change
the permissions of p{u,}mount
Afaik, fedora has pam_console or something like that does something like
you suggest; give privileges to all users that log in at the console.
Also dbus has some support for this, but this isn't compiled in the
debian version, because of the caveats I outlined above.
Thanks, I'll check it.
FWIW, there has been some discussion and ideas floating
around on the HAL and DBus lists. The current consensus is that we need
a secure way for dbus/hal to know what is the current active virtual
terminal and how owns it. For mulit-head systems we need a way to
specify that certain devices (think usb ports) belong to a certain
display.
Nobody has had time to implement it yet however.
Good to know. So I'm not wasting time when constructing a (simple) solution
for my situation.
Gernot
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gdm/Gnome/KDE and device permissions
Sam Morris, 2006-10-11 13:40:08 +0200 : I think HAL/PolicyTool/pam_foreground will eventually give us a (slow?) solution to problems like this, but it's some way off at the moment. Being able to add/revoke permissions with traditional security methods (i.e. group membership) requires kernel modification AFAIK. One could envision usage of POSIX ACLs. Very hackish, but some daemon could add an ACL entry to various files in /dev when a user logs in, or logs out, or time passes, or some device is plugged in, or whatever. No need for special groups. Of course, maintenance would probably be a nightmare, unless there's a way to share ACLs between files that I'm not aware of. Roland. -- Roland Mas Ace of clubs? Let's see that. European Juggling Convention -- Carvin, France. http://ejc2004.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gdm/Gnome/KDE and device permissions
On Wednesday 11 October 2006 14:12 pm, Gernot Salzer wrote: Don't mechanisms like libpam_devperm grant exclusive access? On login the ownership of the devices is set to the console user, and only the owner is granted rwx-rights. On logout ownership/permissions of the device revert to the old setting. That doesn't prevent a user from e.g. writing a program to keep /dev/dsp open after logout and then on request play a sound clip designed to embarrass the current user. -- Daniel Schepler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gdm/Gnome/KDE and device permissions
On Wed, 11 Oct 2006 16:31:37 +0200 Gernot Salzer [EMAIL PROTECTED] wrote: First, there is no safe way to revoke privileges from a user. If a user gets access to a certain group he/she can arrange ways to keep it, even after being logged out (make a suid binary for example). I admit that I don't know much about the internals of Unix/Linux. So, if upon login of user foo ownership/permissions of /dev/audio are set to crw--- 1 foo audio 14, 4 2006-09-22 13:25 /dev/audio and after logout of foo and login of bar to crw--- 1 bar audio 14, 4 2006-09-22 13:25 /dev/audio foo might still be able to access /dev/audio ? One problem is that a user can launch a daemon that keeps the device file open before she logs out Also I was referring to how pam_group works, but I find this way of handling permissions even more broken than pam_group. For example, what happens if somebody logs in on another VT? Second, several people can login at once on different VTs. True, the general case is much more involved. However, considering that the majority of desktops is single-headed, Ever tried ctrl-alt-fn or fast-user-switching? This includes to be able to access devices easily, but without being pried upon by curious (but otherwise friendly and non-hacker) remote users. You maybe right that there are lots of people that are the only user on their systems and for them the objections I have are maybe not important. But going with pam_group or libpam-permdev is broken by design and is not the solution that is going be the standard in the debian. For these people the current setup probably works quite well anyway, because (IIRC) pmount mounts read-only for the user. (If it doesn't you can most probably set it up that way). And because everybody is friendly anyway they won't 'cat garbage /dev/dsp' ;) Why would you want to bring udev in the picture? If you think the scheme used by pam_group (and similar) is secure enough for you, you can also grant access to the plugdev, netdev and powerdev groups. I don't want to grant access to groups but rather want to mimic the behaviour of libpam-permdev that changes ownership/permissions of the device to grant only access to the console user. Maybe udev is the wrong term; with udev I mean the part of the system that creates devices dynamically and thus knows when and at which device e.g. a usb stick was plugged in, and can initiate the action of changing the ownership/permissions. I found a partial solution somewhere on the web working like that. You could probably make a udev rule that does that. But it seems a bit fragile, and again has the same problems as the other methods. grts Tim signature.asc Description: PGP signature
