Re: group ownership of /dev files
also sprach Derek Martin [EMAIL PROTECTED] [2006.06.23.0454 +0200]: My conclusion is that it seems from a security standpoint, and from an ease-of-administration standpoint, pam_console is the clear winner over both of the other proposed solutions. So yes, when I said pam_console was nice, I meant it, and I stand by that. Have I missed something in my analysis? If I have, I would certainly like to learn what it is. Go ahead then and use it. But please do not make statements about Debian not meeting the requirements of seasoned Unix admins such as yourself. We, as in Debian, are going one path with our system, and while someone might well like to deviate, one thing you cannot say is that we don't reason with every step we take. Based on the above analysis, I rather strongly disagree. In every way, pam_console seems up to the challenge, though it needs the enhancement I mentioned regarding killing user processes before it is truly ready. Doesn't sound like a solution I'd want on my machines. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system sed -e '/^[when][coders]/!d' \ -e '/^...[discover].$/d' \ -e '/^..[real].[code]$/!d' \ /usr/share/dict/words signature.asc Description: Digital signature (GPG/PGP)
Re: group ownership of /dev files
On Fri, Jun 23, 2006 at 10:16:26AM +0200, martin f krafft wrote: also sprach Derek Martin [EMAIL PROTECTED] [2006.06.23.0454 +0200]: My conclusion is that it seems from a security standpoint, and from an ease-of-administration standpoint, pam_console is the clear winner over both of the other proposed solutions. So yes, when I said pam_console was nice, I meant it, and I stand by that. Have I missed something in my analysis? If I have, I would certainly like to learn what it is. Go ahead then and use it. But please do not make statements about Debian not meeting the requirements of seasoned Unix admins such as yourself. Why should I not make such statements? If Debian is not meeting the needs of people who want to use it, why should the Debian community not strive to meet those needs? Is the Debian community not open to change for the better? Are its developers not open-minded enough to consider that a solution they previously dismissed might not actually better than the one(s) they've proposed? I certainly hope that's not the case. We, as in Debian, are going one path with our system, and while someone might well like to deviate, one thing you cannot say is that we don't reason with every step we take. I never said you didn't... but can you provide a logical reason for discluding support for pam_console? Can you find any fault with my analysis? You may not personally like pam_console, but it appears to be technically superior to all of the debian-supported solutions to the problem of how to provide access to system resources to workstation users -- a problem which lots of sysadmins must wrestle with. So what logical reason is there not to include it? Does Debian not strive to be the best distribution it can be, meeting the needs of as many users as it can? I'm not asking these questions rhetorically, I'm quite serious. And if you have a logical technical argument against pam_console, I'd still like to hear it. Based on the above analysis, I rather strongly disagree. In every way, pam_console seems up to the challenge, though it needs the enhancement I mentioned regarding killing user processes before it is truly ready. Doesn't sound like a solution I'd want on my machines. Fine. But, why? I don't think ...because I don't like it is a very reasoned or sensible justification, but that seems to be the only justification you are willing to offer. This is starting to seem an awful lot to me like unreasoned anti-RedHat prejudice getting in the way of providing solid technical solutions to real problems faced by real users every day... -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D pgpe0eTuZslp7.pgp Description: PGP signature
Re: group ownership of /dev files
also sprach Derek Martin [EMAIL PROTECTED] [2006.06.23.1403 +0200]: Why should I not make such statements? If Debian is not meeting the needs of people who want to use it, why should the Debian community not strive to meet those needs? Is the Debian community not open to change for the better? Sure, for the better. In this case, however, you are the only one who thinks it's better. You are welcome to package libpam-console and see if others fly by it. I never said you didn't... but can you provide a logical reason for discluding support for pam_console? Please go through the numerous discussions on the topic in the list archives. You are not the first to raise this issue, you know? Can you find any fault with my analysis? You may not personally like pam_console, but it appears to be technically superior to all of the debian-supported solutions to the problem of how to provide access to system resources to workstation users Then I suggest you take a look at the code. And if you have a logical technical argument against pam_console, I'd still like to hear it. It's an ugly hack that will cause more problem than it's worth. Please, go ahead and try it. Fine. But, why? I don't think ...because I don't like it is a very reasoned or sensible justification, but that seems to be the only justification you are willing to offer. You are talking about killing processes and you're asking me why? How, for instance, do you want to cope with the situation of letting a second user log in in KDE or Gnome while the first session is locked? Just kill the first session? This is starting to seem an awful lot to me like unreasoned anti-RedHat prejudice getting in the way of providing solid technical solutions to real problems faced by real users every day... Go ahead and provide the solid solution then. Don't expect others to do it for you. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system arguments are extremely vulgar, for everyone in good society holds exactly the same opinion. -- oscar wilde signature.asc Description: Digital signature (GPG/PGP)
Re: group ownership of /dev files
On Fri, Jun 23, 2006 at 02:27:19PM +0200, martin f krafft wrote: also sprach Derek Martin [EMAIL PROTECTED] [2006.06.23.1403 +0200]: Why should I not make such statements? If Debian is not meeting the needs of people who want to use it, why should the Debian community not strive to meet those needs? Is the Debian community not open to change for the better? Sure, for the better. In this case, however, you are the only one who thinks it's better. Given that, as you say, there are numerous discussions on the net about it, that obviously can't be true. Let me say that my purpose in pursuing this argument is to understand what the reasons are. I'm not attempting to attack you or Debian for their decision. I'm simply trying to understand it. Thusfar, I haven't seen any logical, technical argument that makes that decision make sense... I never said you didn't... but can you provide a logical reason for discluding support for pam_console? Please go through the numerous discussions on the topic in the list archives. You are not the first to raise this issue, you know? I have already looked at several which you and others have brought up. In every case I've seen so far, I've shown that pam_console is at least no worse than the alternatives, and often actually better. Can you find any fault with my analysis? You may not personally like pam_console, but it appears to be technically superior to all of the debian-supported solutions to the problem of how to provide access to system resources to workstation users Then I suggest you take a look at the code. If the code is bad, it can be fixed. In principle though, the approach that pam_console takes is technically superior to all of the alternatives. You say that Debian has considered pam_console and rejected it for good reasons. I'm trying to find out what those reasons are... If the sole technical objection to it is bad implementation, why didn't the Debian developers decide to simply fix the code, as they have done with so many other projects? People have pointed me at a few discussions, but in regards to each of those discussions, all of the supported methods are actually worse than pam_console, as I've shown. Did you read my analysis, and seriously consider what I wrote? And if you have a logical technical argument against pam_console, I'd still like to hear it. It's an ugly hack that will cause more problem than it's worth. That's not a technical argument. It's simply an opinion for which you have provided no basis. I've managed hundreds of Red Hat systems which used it, made extensive use of it myself, and have encountered no such problems. It does, however, effectively provide access to peripherals to anyone who logs in on the console. Your assertion appears to be baseless. Fine. But, why? I don't think ...because I don't like it is a very reasoned or sensible justification, but that seems to be the only justification you are willing to offer. You are talking about killing processes and you're asking me why? How, for instance, do you want to cope with the situation of letting a second user log in in KDE or Gnome while the first session is locked? Just kill the first session? First of all, my intention was that this extension should be an option, not mandantory. PAM allows the modules to have options... If that option is not appropriate for your installation, don't use it. Even without it, pam_console still is more secure (at least in principle, without considering the actual implementation) than the two alternate solutions the Debian community seems to favor. Secondly, how do you propose to allow more than one user to log into the same console simultaneously? The only way this scenario is plausible is if there is more than one physical console attached to the system, or if the same user wants to start multiple sessions in different virtual consoles; this kind of usage is relatively rare, and in either case that particular feature is obviously not for you. But also in that case, someone is going to lose out on using the peripherals, guaranteed. A technical solution which accepts this idea is possible. pam_console could create a lock file, which it would use to determine whether or not someone was already using (or at least had the rights to use) the hardware. If so, it would not reset the permissions upon a second user's login. This is starting to seem an awful lot to me like unreasoned anti-RedHat prejudice getting in the way of providing solid technical solutions to real problems faced by real users every day... Go ahead and provide the solid solution then. Don't expect others to do it for you. Isn't that precisely what Linux distributions do? They provide solutions for people so they don't have to do it themselves... -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D pgpEWSECNWLMQ.pgp Description: PGP signature
Re: group ownership of /dev files
also sprach Derek Martin [EMAIL PROTECTED] [2006.06.23.1527 +0200]: Sure, for the better. In this case, however, you are the only one who thinks it's better. Given that, as you say, there are numerous discussions on the net about it, that obviously can't be true. In this case it is, or are there people agreeing with you *in this thread*? If not, invite the others to join, unless, of course, they've changed their mind. I have already looked at several which you and others have brought up. In every case I've seen so far, I've shown that pam_console is at least no worse than the alternatives, and often actually better. Then please use it. If the code is bad, it can be fixed. Then please fix it. If the sole technical objection to it is bad implementation, why didn't the Debian developers decide to simply fix the code, as they have done with so many other projects? Because noone of us wanted to use it, apparently. Remember, we're volunteers, we do work that we want to do. We don't really work on request. Did you read my analysis, and seriously consider what I wrote? Yes. As said, please take it up and provide a well-tested libpam-console package that does not fall short to the concerns I and others have raised. Go ahead and provide the solid solution then. Don't expect others to do it for you. Isn't that precisely what Linux distributions do? They provide solutions for people so they don't have to do it themselves... No. We collect solutions by people so that others don't have to redo them. In this case, we'd collect your solution. Anyway, since I am of no help to you, I'll withdraw from this discussion. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system it is ok to let your mind go blank, but please turn off the sound. signature.asc Description: Digital signature (GPG/PGP)
group ownership of /dev files
Hi folks, If there's a more appropriate place to ask this, please let me know. I manage a large number of workstations which run Debian. Everyone in my organization need to be able to access any of these workstations, and they expect basic services (like sound, for example) to work properly. Red Hat has a nice PAM library that lets people access, say, the sound devices when they log in on the console. Thus anyone who logs in automatically has access to the sound devices. However, this facility appears to be lacking in Sarge. Note: it is not possible for me to add everyone to the audio group. The workstations get all authentication and group memberships from corporate resources which I do not control. And, even if it were possible, it would be a very bad solution given the large number of machines and large number of users; it would be a maintenance nightmare. Conveniently, everyone who needs to access these machines is in a common group. So, barring trying to compile pam_console for debian and making a custom debian package of it, which I don't want to get involved with, the obvious solution, by far the cleanest and most appropriate solution, is to change the group ownership of the necessary devices to that group. Sounds simple, doesn't it? Except that Debian seems to have some mechanism which, at boot time, resets the group ownership of /dev files. Worse yet, there seems to be more than one of them... I found /etc/init.d/makdev AND REMOVED IT, but despite that, the /dev file ownerships are still getting reset at boot time. Thus, whenever the systems are rebooted, users can't use sound. It's understandably annoying to them, which makes it rather annoying to me. ;-) Anyone know how I can make this stop? Or alternately, know a different way to solve this which I have not already discussed? FWIW, as a long-time system administrator of Unix systems in a wide variety of environments, I consider this behavior highly undesireable, and would like to suggest to any developers listening that they consider changing that behavior. It combined with the lack of pam_console or something like it, this behavior makes managing user access to devices quite difficult. If you're managing your own box, it's a simple matter to add yourself to the audio group; but in many different computing environments, that's just not a feasible option. Thanks. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D pgpHJvM6ybrbx.pgp Description: PGP signature
Re: group ownership of /dev files
On (22/06/06 16:56), Derek Martin wrote: Hi folks, If there's a more appropriate place to ask this, please let me know. I manage a large number of workstations which run Debian. Everyone in my organization need to be able to access any of these workstations, and they expect basic services (like sound, for example) to work properly. Red Hat has a nice PAM library that lets people access, say, the sound devices when they log in on the console. Thus anyone who logs in automatically has access to the sound devices. However, this facility appears to be lacking in Sarge. Note: it is not possible for me to add everyone to the audio group. The workstations get all authentication and group memberships from corporate resources which I do not control. And, even if it were possible, it would be a very bad solution given the large number of machines and large number of users; it would be a maintenance nightmare. A reference. http://lists.debian.org/debian-devel/2002/07/msg01521.html I haven't used pam_console but it does sound quite undesirable. Have a look in /usr/share/doc/udev, that will tell you how to disable udev. James -- James Westby [EMAIL PROTECTED] http://jameswestby.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: group ownership of /dev files
also sprach Derek Martin [EMAIL PROTECTED] [2006.06.22.2256 +0200]: Red Hat has a nice PAM library that lets people access, say, the sound nice. right. devices when they log in on the console. Thus anyone who logs in automatically has access to the sound devices. However, this facility appears to be lacking in Sarge. by choice, yes. http://lists.debian.org/debian-devel/2001/06/msg00944.html check out pam_group and /etc/security/group.conf for another approach, which is not secure (read comments), but a little better. Except that Debian seems to have some mechanism which, at boot time, resets the group ownership of /dev files. You are probably using udev which creates them after boot. dpkg -l udev Anyone know how I can make this stop? Or alternately, know a different way to solve this which I have not already discussed? You could help with modularisation of makedev, which will allow you to specify policies for device files. FWIW, as a long-time system administrator of Unix systems in a wide variety of environments, I consider this behavior highly undesireable, and would like to suggest to any developers listening that they consider changing that behavior. dpkg -P udev you get what you ask for. Now if you're not using devfs but a plain /dev, you should be fine. df /dev | grep -q '/$' echo now everything should be okay \ || echo got work to do -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system moderation is a fatal thing. enough is as bad as a meal. more than enough is as good as a feast. -- oscar wilde signature.asc Description: Digital signature (GPG/PGP)
Re: group ownership of /dev files
On Thu, Jun 22, 2006 at 04:56:13PM -0400, Derek Martin wrote: Red Hat has a nice PAM library that lets people access, say, the sound devices when they log in on the console. Thus anyone who logs in automatically has access to the sound devices. However, this facility appears to be lacking in Sarge. You could try the pam_group solution, which isn't ideal but does work, which is described here: http://www.debian-administration.org/articles/308 Steve -- http://xen-tools.org/ signature.asc Description: Digital signature
Re: group ownership of /dev files
On Thu, Jun 22, 2006 at 11:07:37PM +0200, martin f krafft wrote: [pam_console] devices when they log in on the console. Thus anyone who logs in automatically has access to the sound devices. However, this facility appears to be lacking in Sarge. by choice, yes. http://lists.debian.org/debian-devel/2001/06/msg00944.html I agree the post's points are valid... However how is this any worse than adding all the users to the audio group (a solution recommended in that very message, and many other posts on various debian lists)? Either way, this is still possible... In my scenario, everyone who uses these machines would need to be added to the audio group. So there is no gain in security here by comparison. I would argue that pam_console is actually better, because it offers only the temporary ability to do this, and the user had to log in on the console to get the privilege in the first place. Using the group method, EVERYONE in the group can do this at any time, as long as the sound device isn't already open by someone else. Any such user can log in remotely and repeatedly open the sound device whenever any other user releases it... So, I don't see how you can argue that using a group is better than pam_console. And in any event, the only problem it causes is a DoS of that resource, which the system administrator can fix right quick, and can disable the account of the offending user. This is annoying, but it's not really a big deal, and the user can be dealt with in other ways. IIRC pam_console also has mechanisms to prevent it from working for specific users/groups, so there again, it would seem to be a better solution. I might be mistaken on that last point though; it's been years since I had any reason to configure it beyond Red Hat's defaults. But anyway... check out pam_group and /etc/security/group.conf for another approach, which is not secure (read comments), but a little better. Thanks for the tip... this may work, though at a quick glance, again, I don't see how this is better than pam_console. You are probably using udev which creates them after boot. dpkg -l udev Yup. Anyone know how I can make this stop? Or alternately, know a different way to solve this which I have not already discussed? You could help with modularisation of makedev, which will allow you to specify policies for device files. Is udev using makedev, or equivalent? If not, I would think that the better way to go would be to look into configuring policies in udev... In particular, it would be nice if whatever is managing the devices noticed that the device files exist already, and leave them alone if only the permissions and/or ownerships have changed. dpkg -P udev Any potential gotchas to doing that? It might be the right solution for my purposes... you get what you ask for. Now if you're not using devfs but a plain /dev, you should be fine. FWIW, I didn't ask for udev. It appears to be the default... I'll need to read up on udev, and see what it provides. Been meaning to do that for a long time now... ;-) Thanks for your response, and thanks to everyone else who responded. It looks like a real solution to my problem is going to have to wait until I do a little more research, but at least I know what to look at now. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D pgp2ra1OBTESf.pgp Description: PGP signature
Re: group ownership of /dev files
also sprach Derek Martin [EMAIL PROTECTED] [2006.06.23.0017 +0200]: Thanks for the tip... this may work, though at a quick glance, again, I don't see how this is better than pam_console. It does not mess with the filesystem for a start. And no, it won't get rid of the security issues. You could help with modularisation of makedev, which will allow you to specify policies for device files. Is udev using makedev, or equivalent? Yes. If not, I would think that the better way to go would be to look into configuring policies in udev... You can do that too. In particular, it would be nice if whatever is managing the devices noticed that the device files exist already, and leave them alone if only the permissions and/or ownerships have changed. By the time udev creates it, the device file does not exist. udev uses a tmpfs, which is a filesystem in RAM, which is empty after boot. dpkg -P udev Any potential gotchas to doing that? It might be the right solution for my purposes... it might screw up the system(s), but it might also work. You won't get the benefits from udev anymore, obviously, which include better control over device naming, permissions (ha!), scripts, hotplugging, etc. you get what you ask for. Now if you're not using devfs but a plain /dev, you should be fine. FWIW, I didn't ask for udev. It appears to be the default... What did you install? sarge? No udev default for sarge. But yes, unfortunately, it will be default in the future. Thanks for your response, and thanks to everyone else who responded. It looks like a real solution to my problem is going to have to wait until I do a little more research, but at least I know what to look at now. There is no solution to your problem, not on a multiuser operating system. There are plenty of approaches, but none of them cater against malicious users. If you don't have any of those (haha), then pam_group is IMHO the best approach. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system SUSE: Soll Unix Sein, Eigentlich. signature.asc Description: Digital signature (GPG/PGP)
Re: group ownership of /dev files
On Fri, Jun 23, 2006 at 12:41:51AM +0200, martin f krafft wrote: also sprach Derek Martin [EMAIL PROTECTED] [2006.06.23.0017 +0200]: Thanks for the tip... this may work, though at a quick glance, again, I don't see how this is better than pam_console. It does not mess with the filesystem for a start. OK... but how is this a win? One of the reasons devices were implemented as files was to make precisely this kind of manipulation easy. It's simple, efficient, and it works as expected. Let's try to make a fair technical analysis. Think about what problem we're trying to solve: access to physical devices connected to the hardware. Who should be able to access those devices? It the overwhelming majority of cases, the person who is sitting in front of the hardware, i.e. logged in at the console. That person changes each time someone new logs in and logs out. If it were data in a file to which the user needed access, we would just change the permissions on the file. But the point is, devices are just files. They were designed that way specifically so there would be no difference in the way they are treated. Thus, the most obvious, logical, and efficient way to change the access to those resources is to change the permissions on the device file to that of a user who logs in at the console. That's exactly what pam_console does, precisely in the way that Unix was originally intended and designed to do it... As for the security implications of someone logging in at the console and holding the resources hostage: with the pam_console solution, far fewer people can do this (only the last person to log in at the console) than can do so if you just add trusted users to the audio group. In the latter case, anyone in the audio group can execute such an attack, at any time. In that regard, while admittedly still flawed, pam_console appears technically superior to adding users to different groups for each of the device classes. And from a systems management point of view, it involves no administrative overhead, whereas maintaining group files (or other authentication mechanisms like LDAP) can become an administrative nightmare if you have a large number of users. There again, pam_console appears to be superior. Now let's compare pam_console to the other solution that's being offered here: pam_group. In most regards, pam_group actually seems to be very similar to pam_console. However, with pam_group, the user may temporarily assigned to new groups. While they have those group privileges, as the referenced document itself points out, there's nothing stopping the user from making their own SGID binaries that grant them that privilege permanently. Can such a privilege escalation be executed using pam_console? No. pam_console only grants temporary access to a specified resource to a user, by changing the permisisons on the resource to that which the user already has... No additional privileges can be gained in that manner. Here again, pam_console appears to be the winner. [We must ignore the possibility of an unknown priviledge escalation (probably to root) caused by a programming error in the pam libraries themselves; such a bug could exist in either library.] Additionally, while I don't think it currently does this, there's no reason I can think of that pam_console can't be extended to find all of the user's processes which are accessing the devices (or files) it is managing, and kill them after (not before -- race condition) it changes the permissions back. Obviously I already favor this approach to managing the problem, and I think if such an extension were coded up, it would make pam_console a vastly superior solution to the problem compared to any other which has been mentioned here. As far as I can see, that would completely close all of the security holes associated with granting users access to the device files. [Note though that pam_group could certainly be extended in the same way... If I get bored enough, I might just look into coding that up (as an option) for both libraries. Both could probably benefit from a common module of functions that does this.] My conclusion is that it seems from a security standpoint, and from an ease-of-administration standpoint, pam_console is the clear winner over both of the other proposed solutions. So yes, when I said pam_console was nice, I meant it, and I stand by that. Have I missed something in my analysis? If I have, I would certainly like to learn what it is. Why are inquiries on this list about the functionality of pam_console met with such contempt and disdain? Such a response doesn't seem to hold up to technical analysis, and in fact appears to be entirely baseless. There is no solution to your problem, not on a multiuser operating system. Based on the above analysis, I rather strongly disagree. In every way, pam_console seems up to the challenge, though it needs the enhancement I mentioned regarding killing user processes
