PAM console.perms (and xlockmore)

[SpoonMeiser]

I don't know a lot about security, but I know what I like... and it isn't pam.
At least not how it changes the ownership of devices to the first user who logs in. The other day, I had the brilliant idea of emerging Open Office...
'while that's installing,' I thought, 'I can play Quake'.
But alas, root had been given exclusive rights to use all the sound devices, and /dev/nvidiactl.

So, what I actually want to know is, what have other people done who have found the same problems with pam? have they just taken everything out of /etc/security/console.perms of have they found an alternative to pam?

Also, has anyone else had a problem with pam not actually giving the first user to log in ownership of all the relevant devices? I often find that games don't have sound because pam has forgotten to give me rights to /dev/dsp, although it's given me rights to most other devices (including /dev/nvidiactl). There doesn't seem to be a bug concerning this, and I'm not entirely sure how to reproduce it.

One other thing that I found quite interesting, is that pam can completly undermine the use of xlockmore to keep your desktop secure while you wander off for a minute or two. If someone else has logged into your box first, even on a console, or (I believe) even remotly, pam will give them ownership of /dev/nvidiactl and when xlockmore comes around to displaying an openGL screensaver, it just stops, dumping you back at the desktop with an error message, without requiring a password. Of course this is easy to fix by taking /dev/nvidiactl out of /etc/security/console.perms but this is the default behavour of pam on Gentoo.

[SpoonMeiser]

After a bit more playing around... it appears that /dev/dsp (or /dev/sound/dsp which it is a link to) only actually appears after you try to use a sound device. This is why PAM doesn't give me all the relevant permissions on login. ALSA works fine, but I guess the default permissions are too restrictive for OSS to work, meaning that I have to fire up a root session and run `pam_console_apply`... which is rather annoying.

What do other people use instead of PAM?

[Sven Vermeulen]

I love pam, maybe because the authentification at work is using PAM and I got a good description about it. About the console.perms, just change it so that the devices are read/writable by the group "audio" and add your users to that group. This is a FAQ iirc.

[SpoonMeiser]

Why is PAM good? I've never used it before, and I wondering what the benifits are.

Admitedly this is the only problem I have with it. However, this whole console.perms thing seems a very stupid idea to me. Your suggestion would effectivly remove the effect pam has on console permissions, but isn't there a way just to tell PAM not to bother in the first place?

[Sven Vermeulen]

You're probably using it constantly: all distributions use PAM for authentification. pam is a default USE-setting, btw.

Check /etc/pam.d/, it contains the authentificationrules for all pam-supported tools on your system: login, passwd, sshd, su, sudo, useradd, ...

The benefits are a coherent configuration and a very big flexibility. At work, everyone has to authenticate himself before entering the datacenter. This happens with smartcards and a password. Authentification is handled by PAM.

A good introduction to pam can be found at http://www.kernel.org/pub/linux/libs/pam/ and more specific http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/pam.html

[SpoonMeiser]

Ok, thanks for the help. I guess I should have checked that site first...

I still maintain that the whole idea of pam_console is very silly, and I've removed it from the pam.d files.

I've set up pam to now add users to the audio group if the user is local, and the video group if they're logging into X. I know there are vulnerabilities involved with this approach, but it's a relativly trusted environment, and if it's abused, I can require people to be members of a 'trusted' group before gaining video or audio group membership.