The default setup of pam_console gives all users logging in on the local machine full read/write access to serial ports! This is not only completely unneccessary, but also a HUUUUGE SECURITY RISK if there is a modem connected to it! Every user with a local account (or anyone else if he's been trojaned) can dial any number he wants! Even very expensive ones!!
Hey can somebody on the pam team verify/debunk/fix this one.
Hans, It gets worse. Peep the permissions on all of /dev/tty[a-z,0-9] in any of the stages. Also as it seesm nobody from the pam team is willing to comment on this bug, I ask you to please try to locate a patch/fix/work around for this and attach it here.
I verify that it exists almost as described. on console login (and ONLY if no other users are logged in at the console) /dev/ttyS* is changed to 660, $user:tty on logout it reverts to 660, root:tty this only allows access for the user that logs in at the console. as a solution to this, here is a fix: --- /etc/security/console.perms.old 2003-10-15 16:59:35.000000000 -0700 +++ /etc/security/console.perms 2003-10-15 17:00:02.000000000 -0700 @@ -53,7 +53,7 @@ /proc/usb/[0-9][0-9][0-9]/[0-9][0-9][0-9] # permission definitions -<console> 0660 <serial> 0660 root.tty +#<console> 0660 <serial> 0660 root.tty <console> 0660 <floppy> 0660 root.floppy <console> 0600 <sound> 0600 root.audio <console> 0600 <cdrom> 0660 root.cdrom This ensures that the serial devices are always owned root:tty with 660 perms. Any user that then needs serial access gets put into the tty group. Acceptable? I don't think the additional risk by having a modem connected for a local user is that serious, as if somebody has physical access to the machine, they can quite easily just dial the same very expensive phone numbers from the phone there or do a lot worse to the machine.
think trojans or serial terminals
*BUMP* still a problem in pam-0.77
PAM folks -- have we committed this fix?
hum-de-dum-dum
sent an email to pam-bugs@gentoo.org directly asking for input/action on this bug.
Well, what did they say?
nothing -- received no response.
if you have trojans, this is the least of your worries (I'm not aware of ANY trojan for linux that even touches serial ports, let alone dials out), they can do a lot more with your machine than just make money. If you can show me a trojan that does this and prove you aren't just being paranoid beyond reason Requiring a user to be in the tty group to use the devices is an acceptable trade-off, as it does massively decrease the risk. Perhaps an further improvement would be to change the ownership to root:serial and create a serial group.
<SIGH> It's getting really hard to defend there's a problem if nobody seems to see there is one. So let me try something different: The original PAM sources don't have pam_console; and don't have the problem. RH's patches add pam_console, but their config file leaves /dev/ttyS* alone (last time I checked, around 0.75); no problem there either. This means gentoo maintainers added this permission change. Why?? Most common devices attached are: 1. serial mice: after initial setup (xserver or gpm) provide only readonly data; no write access needed. 2. modems: 2.1 pppd already needs to run with root-privs (so it can modify network settings), so it can access ttyS* no matter what. 2.2 other communications progs (minicom, etc.) usually require users to be members of a dedicated group to be able to dial; BUT: if pppd is set up to be group executable by a special group, pppd group != serial group. (pppd is way more powerful) 3. serial terminals 4. other devices (eprommers, smart card programmers, ADCs, etc.) probably not common and standardized enough for inclusion in default setup, sys-admins should know how to handle those. </SIGH> Please don't abuse the 'tty' group once more for any of those; 'tty' is reserved to allow sgid talk/wall/write programs access to other users' (pseudo) terminals; IF the user chooses to allow such access (man mesg). 'tty' is not meant to have any users in it as that would make mesg access control practically useless. Thanks.
instead of repeatedly claiming we don't get the problem and disagreeing with my solutions posted last october, could you provide what your solution is, and what it leaves permissions as? I've checked up on a number of redhat boxes now, and while they don't change serial port perms using pam_console, all the serial devices are owned root:uucp with perms 660, and the other tty devices are root:tty with perms 666. This defeats the purpose of any mesg access control to a degree anyway. I don't know the entire origins of the configuration that's in question, it seems to predate me being a gentoo developer. For serial devices to work, the serial devices will need more perms than they have presently (to add read as you note), but this opens up an attack on serial consoles (which are exceedingly rare in this day). The configuraation would be insecure by default if we have a default configuration to allow serial mouse usage. For other devices, a set[ug]id program to handle the serial port is very common, see NUT's upsdrv setup for a very good design on this.
I didn't do any of that; in fact the solution posted last october would have solved all the problems as far as PAM is concerned; just don;t see it in protage yet........except it's much easier tonot apply a bogus patch in the 1st place patch instead of undoing it in a later patch. Sorry I was a bit unclear about ser. mice; ofcourse once gpm/x11 have opened the device as root, they;'' always have read perms; only thing that counts is permisiions at opentime. Teh thing I;, getting at is, experiences sys-admins know how to add premissions if theire toos trict, but inexperienced admins dont know how tro remove too permissive permissions they don;';t know about (sure tty devs connected to logins are still 666in RH? seems like a relally really really bad idea to me) The lasr comment in comment #13 was a jib at the gentoo handbook which now recommends putting nwe users int he 'tty; group, clearly bad idea; and your suggestion to make ttyS* gid tty (ttyS* !!== tty*!)
Well, all joking aside, could somebody please fix this? If a user is logged in into /dev/ttyS0, as soon as a user logs in on a local virtual console, pam_console hijacks ttyS0 and now it is owned by <local-user>:tty mode 660. Worse yet, now that the manual says to put users in the "tty" group -- no offense but quite frankly one of the stupidest things I've ever heard -- all users can read/write to/from ttyS0. I don't even want to think what happens if ttyS0 is a dial-in line. thanks, _rnz_
Paranoid! :/
implementing solution as described by comment #3.
Robin -- did you have a chance to implement this?
Seeing as how this was reported almost a year ago, I guess I'll roll my own ebuild. Thanks, lads, anyway.
In the process of making snide comments, did you notice comment #3? Specifically, the one line patch? Does this work for you or not? Do you have an alternate solution or not? There has been a lot of whining about the one solution Robin proposed but, to date, that's been the only actual code contributed to fix the problem. Help us help you.
Well, I don't know what was going on behind the scenes, but the comments here do not really ecourage people to use the Gentoo supplied PAM solution, as sad as that is, although it goes much deeper than that. The problems as I see them in no particular order.. 1. This seems to be the root, some doc on www.gentoo.org (don't remember exact page) says Although you can set permissions in /etc/devfsd.conf, you are advised to use PAM (Pluggable Authentification Modules). This is because PAM has the final say on permissions, possibly ignoring the changes you make in /etc/devfsd.conf. This is wrong. pam_console is NOT designed to manage and/or set device permissions. It can be used to give users ownership to devices while they're logged in, if it makes sense. Example devices would be floppy, cdrom, audio, but NOT serial ports. Also Gentoo should decide on one method, pam_console OR floppy,cdrom,audio,etc. groups, but not both. A couple of minutes of research brings up many bugs on lost device permissions in spite of correct group membership that would not exist if PAM was configured properly. 2. As correctly identified in an earlier comment, the erratic behaviour described here results from a patch in the "gentoo-patches" subdirectory in pam-0.77-patches-1.{0,2}.tar.bz2, and judging from earlier comments also in similar pam-0.75 patch sets. I can only guess here, but from the documentation error described in (1) it looks like someone tried to manage /dev/ttyS? permissions with pam_console. This is wrong for many reasons.. - unlike floppy and audio devices serial ports are typically not assotiated with ONE local user only. They may have active logins or modem connections on them, but still pam_console would give ownership to the first local user. - when pam_console's session module is called it would be much too late to set permissions on the line the user just logged in anyway. If pam_console would trigger on serial logins anyway. If that were PAM's responsibility to begin with. - usually it's package managers who accept or reject patches from users, not the other way around. I not only don't know why said patch exists, all I can do speculate and say this, even if this sounds harsh, it's dangerous nonsense. Users do not need this kind of access. 3. The tty group. This actually worries me most about this whole discussion. In various comments here it was suggested to make users member of tty. The install guide suggests the same, pam_console makes /dev/ttyS? group tty when user logs out. "udev.permissions" says # pty devices # Set this to 0660 if you only want users belonging to tty group # to be able to allocate PTYs This is sooo wrong. The tty group has, and always had, a very specific purpose in the *nix world, to change that requires patches to many many packages that have this group hardcoded into them, including util-linux, shadow, sysv-init, sshd, various terminal emulators, the whole pty code in libc, and many more. Repeat, there should be no normal users in tty, ever. All basic *nix admin 101 knowledge, yet nobody sees/complains/cares to fix all this. I apologise in advance if this sounds harsh again, but what would you suggest, to use the Gentoo provided default solution or write my own? Thanks, __rnz__
i know! why dont you convert pam changelog to xml format? That instantly solved all pam problems in the company i worked for *and* will help make gentoo ready for the enterprise market!
I think you're on the wrong site. Trolls are found over on forums.gentoo.org. But really, your efforts are fairly amateurish -- you'll have to take it up a couple notches if you expect to compete with the big boys. Come back when you've grown some peach fuzz on your chin and we'll talk.
Regarding comment #22, you did a decent job of outlining the problems, as you perceive them. However, I didn't see where you provided a solution. How about providing some patches that fix things the way you'd like to see them fixed?
To date, we have a few vocal users who are concerned about this issue. We have not received a huge number of complaints about this, so I have to assume that either a) the issue is so obscure that few people will actually notice it or b) the issue isn't really a problem at all. There has been one solution, including patches, proposed. (see comment #3) Those same vocal users have expressed dissatisfaction with this solution, but they have not offered anything better. We are a community distribution. We rely upon the efforts of our community to help make Gentoo better. If you do not like the proposed solution, PLEASE SUBMIT PATCHES FOR A BETTER SOLUTION. I have asked for this REPEATEDLY and, so far, haven't seen anything. I don't want further discussions about the problem. I want to see how you would fix it, including patches. So, here's formal notice: If you do not submit patches within 48 hours, I'm going to close this bug as wontfix. Sorry if that comes across as rude, unhelpful or otherwise not friendly. I've tried asking nicely before and that hasn't gotten this bug any closer to being resolved. So, I'm trying the blunt approach.
That's a joke, right? Here we have a case that on some setups allows unpriviledged users to do much nastier things than with the occasional buffer overruns, which (rightly so) are scheduled for removal from portage if no fixes are known, and here you want to close it WONTFIX??? As I said a couple of days ago, I don't think it's a good idea to ask users for patches. First of all, how do you know you can trust me? Second of all, I don't know why Gentoo PAM behaves in the way it does. Now, IF the first reaction from a PAM ebuild maintainer would have been This is caused by [patch X] It exists because [problem Y] See [bug #Z] THEN it would have been easy to address [problem Y] the proper way and make it safe to remove [patch Z]. Now let's see what happened here * Comment #2 doesn't even parse. What do master PTYs have to do with serial ports? Why would anyone use them now that ptmx and devpts are in use for many years? (IF they were used the using application / openpty would of course take care of proper permissions). * Comment #3 presents a patch that partly removes the effects of a previous patch. However, IF, as stated in that comment, new ownership is root:tty 660 (where was this set at that time?), it doesn't solve the whole thing. Also, since the (unknown to me) underlying problem whose symptoms you're trying to fight is not addressed at all, next thing you know another user will open a bug that serial ports are not working for them anymore. I sure wouldn't want to be responsible for that. First occurance of calling reporting user paranoid. * silence for a very looong time. * Comment #12 again tries to pretend there is no problem at all. Same mistake wrt tty group. Why not stick with established standards in use for more than a decade? * Comment #26 is what it says, unhelpful. In conclusion, without cooperation from Gentoo developers I can't see this fixed, sorry. Go ahead, close it WONTFIX, it's fine with me. If you think that's the right thing to do. If you can support it. I myself fixed it in about 2 hours (as opposed to almost a year and still no fix). I don't care. Gr
That's a joke, right? Here we have a case that on some setups allows unpriviledged users to do much nastier things than with the occasional buffer overruns, which (rightly so) are scheduled for removal from portage if no fixes are known, and here you want to close it WONTFIX??? As I said a couple of days ago, I don't think it's a good idea to ask users for patches. First of all, how do you know you can trust me? Second of all, I don't know why Gentoo PAM behaves in the way it does. Now, IF the first reaction from a PAM ebuild maintainer would have been This is caused by [patch X] It exists because [problem Y] See [bug #Z] THEN it would have been easy to address [problem Y] the proper way and make it safe to remove [patch Z]. Now let's see what happened here * Comment #2 doesn't even parse. What do master PTYs have to do with serial ports? Why would anyone use them now that ptmx and devpts are in use for many years? (IF they were used the using application / openpty would of course take care of proper permissions). * Comment #3 presents a patch that partly removes the effects of a previous patch. However, IF, as stated in that comment, new ownership is root:tty 660 (where was this set at that time?), it doesn't solve the whole thing. Also, since the (unknown to me) underlying problem whose symptoms you're trying to fight is not addressed at all, next thing you know another user will open a bug that serial ports are not working for them anymore. I sure wouldn't want to be responsible for that. First occurance of calling reporting user paranoid. * silence for a very looong time. * Comment #12 again tries to pretend there is no problem at all. Same mistake wrt tty group. Why not stick with established standards in use for more than a decade? * Comment #26 is what it says, unhelpful. In conclusion, without cooperation from Gentoo developers I can't see this fixed, sorry. Go ahead, close it WONTFIX, it's fine with me. If you think that's the right thing to do. If you can support it. I myself fixed it in about 2 hours (as opposed to almost a year and still no fix). I don't care. Grürzi, __rnz__
Part of the problem is that none of the original PAM people are still with gentoo, they are the ones that put the patch in question into place. I don't know the reason for it's existance, but I believe (but I may be completely wrong) it was for serial devices that a local user generally connects - serial mice and other devices. This was I believe is the "It exists because of problem ..." you ask for. "However, IF, as stated in that comment, new ownership is root:tty 660 (where was this set at that time?), it doesn't solve the whole thing. Also, since the (unknown to me) underlying problem whose symptoms you're trying to fight is not addressed at all, next thing you know another user will open a bug that serial ports are not working for them anymore. I sure wouldn't want to be responsible for that." I checked two stage files for the initial serial devices, that would be in place if pam_console didn't touch them. In the older one, all of /dev/tty* is root:tty/666. In the newer one, /dev/ttyS* is root:dialout/660, and the remaining /dev/tty* is root:tty/666. So depending what stagefile you used, your file perms may be wrong. This is what comment #2 is refering to, and I what I refer to in comment #3. "First occurance of calling reporting user paranoid." I made the paranoid remark for the presumption of a trojaned serial terminal that dials out to some expensive phone number. I can think of far more worse or lucrative things that can be done if a trojan was in place, and I'm not aware of ANY Unix trojan that dials out (such things do exist for Windows however, and have recently been deemed highly illegal in several parts of the world) or (ab)uses a serial port in any way. In comment #12, I noted that a better solution would be to take out this behavior of pam_console wrt to serial ports, and use a serial group ('dialout' exists already for this usage) and ensure the perms of the serial devices are root:dialout/660 - this recieved absolutely no comment from the submitter or Rainer. You only continuted to claim that I would be abusing the tty group, which I'm very aware of. This would break gpm with serial mice, which need read access to the port. And as you note, you'd definetly get users reporting that their serial port devices aren't working because of this, because they aren't in the serial group. You also note that somewhere in the manual it says to put users in the tty group, and nowhere can I find this. Asking users for patches is a perfectly acceptable route to getting things fixed, as you seem to know exactly how you want it fixed, and we are quite capable of reviewing code to check both it's correctness and to weed out nasty things. This procedure gets Gentoo as a distribution much further, and if we regularly see the same users contributing large numbers of good patches to fix things, it's a good sign that they may be worthwhile to have on board as a Gentoo developer. You claim you fixed it in two hours, so post your fix up here, as if you trust it to use it on your own system, I don't see why you wouldn't trust the same fix on other users' systems. In fact, I'd find the choice of knowing the fix, but not sharing it because you think it shouldn't be trusted to be very selfish.
<WORST TIMING EVER> Please don't close this bug as of yet, it's NOT fine with ME! Just to clarify some things, the reason there are next to no Linux trojans is that regular users are not granted access to resources they don't need. Not so on gentoo. One of the wrong sections re: tty group in the manual is 11.a. User Administration [quote] Code Listing 1: Adding a user for day-to-day use Login: root Password: (Your root password) # useradd john -m -G users,wheel,audio,tty -s /bin/bash # <=== BAM! # passwd john Password: (Enter the password for john) Re-enter password: (Re-enter the password to verify) [unquote] Which means, new users following the handbook will be members of tty forever. </WORST TIMING EVER>
So file a bug about the manual. Let me sum up this bug so far: 1. Bug is filed, reporting a problem. 2. Developer: "OK, here's one way we can fix it, along with a patch. What do you think?" 3. Users: "No, we don't like it" 4. Developer: "OK, what would you like to see, then?" 5. Users: "No, we don't like it" 6. Developer: "OK, what would you like to see, then? Do you have patches?" 7. Users: "No, we don't like it. We fixed it on our own, but we're not going to tell you how we did it. Screw you guys." I'm closing this bug for now. If you want us to revisit the problem, PLEASE INCLUDE A VERY DETAILED EXPLANATION OF EXACTLY HOW YOU THINK THIS PROBLEM SHOULD BE FIXED. PLEASE INCLUDE PATCHES ON HOW TO FIX IT. I can't begin to explain how frustrating it is to have people complaining about a proposed solution but refusing to provide a suggested solution of their own. --kurt
Yet another suggestion: Step 1 getting defvs.conf and udev.permissions in sync with static dev tree ------------------------------------------... This is what I see as the root problem...depending on whether you are using udev, devfs, or the traditional static device nodes, serial ports look differently... static: 0660:root:dialout devfs: 0600:root:root udev: 0660:root:tty (allmost everything with `tty' in its name) 0660:root:usb (ttyUSB) required changes: static tree: (as created by `MAKEDEV') looks good... `dialout' is what Debian uses for the same purpose (the other big three use the more traditional `uucp' group) devfsd.conf: add these lines REGISTER ^tts/[^/]*$ PERMISSIONS root.dialout 0660 REGISTER ^cua/[^/]*$ PERMISSIONS root.dialout 0660 REGISTER ^usb/tts/[0-9]* PERMISSIONS root.dialout 0660 udev.permissions: (similar changes to get in sync with devfs) (note that there are other differences that are beyond the scope of this bug... `devfsd.conf' that comes with baselayout more or less does not touch any device permissions/ownerships at all) Step 2 change `console.perms' as proposed in comment #3 ------------------------------------------... I too can't imagine any reason for this line to be there (definitely not for gpm...) However, this leads to another problem (see bug #31877)... On devfsd systems, simply updating `console.perms' will leave permissions to whatever is saved in `/lib/dev-state'... devfsd users should be advised to reset their dev-state and SIGHUP devfsd for the changes to take effect.
everybody here: see bug #31877, if there any reason we need to keep pam_console? Or could it just be ripped out and replaced by appropriate group permissions and memberships?
Well... you don't really need to dump `pam_console' to get rid of this (#28407) bug. The reason I linked to #31877 was actually to point to more information regarding stale nodes in `/lib/dev-state'. As for pam_console, it seems a lot of people active in Bugzilla don't seem to like it. A couple of thoughts... In some environments, there is no real alternative to pam_console... for instance, computer labs. Without pam_console, users who are static audio, floppy, cdrom, etc. group members would be able to remotely log into machines used by other users and read that other user's private floppies, eject their CD tray, play sounds, etc. Not really what they want. On pure home machines without untrusted users, but maybe more than one user logged in locally, quite the opposite is true. pam_console and group-based access are not mutually exclusive... the really important thing is that `revert_mode' and `revert_owner' in `console.perms' match the initial device mode as defined in `MAKEDEV'/`devfsd.conf'/`udev.permissions'. For example, here's how floppy device modes should be configured... Initial mode: 0660:root:floppy After console login: 0600:$user:floppy After logout: 0660:root:floppy If pam_console is being used, console users get exclusive ownership for the time their session lasts, and everything goes back to initial permissions afterwards. Without pam_console, the initial mode is used all the time... This leaves it to the local admin to decide whether to enable pam_console, make users members of appropriate groups, or both...no additional changes needed. (it seems the stock `console.perms' reverts audio devices to `0600:root:audio'. I think this is what Comment #22 and a lot of complaints in Bug #31877 may be referring to ) I could write a more detailed comment to #31877 in a few days, if anyone is interrested. (or preferrably, a new bug...the original problem reported in #31877 is IMO more related to not restoring default modes during system boot after reboots without a "clean" logout...and thus more of a init-script/baselayout bug in my opinion)
Okayyy.. complete fix goes back to Sept, 8, but as of today (Sept 26) resolution still claims you "can't fix" it. What more information/help do you need?
Reopening based on provided information. Robin: please comment on provided solution.
That solution would be fine by me. Please attach diffs for all applicable portions that need to be fixed. (I'm short of time lately, so I'm mainly reviewing+testing instead of writing fixes myself).
no patches or diffs provided. closing.
/me disagrees and voices dissatisfaction with klieber's solution.
Disagree all you want. It's not going to get you anywhere. Provide patches and that might get you somewhere. I've been very, very clear about this and gave several chances for folks to step up and provide patches. Nobody did. So, it's a wontfix. --kurt
"vocal user" speaking: I would agree if this were an enhancemennt request and you were doing this just for me. But it's not! BAM! It's a design flaw and security risc I found worth mentioning that affexts ALL users! You chose to wontfix it! I know how to fix it; everyone followwing this bug knows how to fix it; my doctor ordered absolutely no stress, so that's as far as I will go! That;s why you dont' see me reopening this bug or opening any other one! You (klieber) (presumably speaking on account of security@g.o) classified the problem as "a) the issue is so obscure that few people will actually notice it" or "b) the issue isn't really a problem at all." But it is! BAM! The sample exploitt written by OUR security team in May 2003 permits regular, uprivilegedd users to hijack and/or rplace dialup connections and serial logins back then and still works now! The problem is you don't admit the problem; and no patch in the worlld couldchange that! I found you two people who were willing to help; you ignored them; so BAM! Re: comment #30: Problem is not "we don't like it"; it's "it doesn't change a thing"! For example: Bug #53086 (incidentallly going back to a forums@g.o post, which you identified yourself as "where spammers are found" (comment #24)) led to the handbook error. The problem was properly fixed later in bug #53292! MAKEDEV in recent baselayout chnaged /dev/tty permissions from 666 to 660! Now people using traditional /dev are also required to be tty members. What point is that trying to make??? Like robbat2 correctly pointed out in an earliier comment; oother distributions don't have this requiresment; simple reason being gpm is running as root before any user logs in. What about users with PS/2 or USB mice? should they be tty group members too???? Just does not make sense! Do you want me to open additionall bugs for these at the risk of WONTFIXSs? My doctor would say bad for my health. Upgradding gentoo bugzilla to 10=beer-minimum!
