On Fri, Jun 23, 2006 at 12:41:51AM +0200, martin f krafft wrote: > also sprach Derek Martin <code@pizzashack.org> [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 before it is truly ready. I do thank you all for your answers, and for encouraging me to think much more deeply about this problem then I ever had before. I now have some options to weigh in solving my problem, though I dislike all of them. :( -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D
Attachment:
pgp_cREmzIG8P.pgp
Description: PGP signature