rbw@hpfcdc.HP.COM (Rick Whitner) (06/27/90)
In response to: > >Brian Bartholomew UUCP: ...gatech!uflorida!beach.cis.ufl.edu!bb >University of Florida Internet: bb@beach.cis.ufl.edu > > o HP-UX v7.0, as distributed under the "Instant Ignition" option > (don't get me started about that!), comes with null passwords > for each entry in /etc/group. This allows any user to use > the "newgrp" command, and have the group privledges of root, bin, > or anyone else. I promptly put stars in each password field, > to patch this hole. Later, I used SAM to add a new user account. > It decided to remove the stars from the group entries, without ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I have attempted (unsuccessfully) to replicate the problem you describe here. I placed stars in each password field in /etc/group and then added a new user using SAM. I tried other variations of this same operation and still could not replicate the problem. Perhaps if you could provide more information on the situation/circumstances/configuration/etc., the source of your problem could be identified. > telling me, even though my addition did not require any changes ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > to the group file! This was the last straw, and we took off the ^^^^^^^^^^^^^^^^^^ > executable permission bit from SAM, just to prevent accidents. When a new user is added to the system, /etc/group is modified to add that user to his primary group. SAM uses the functions documented under getgrent(3C) in the HP-UX Reference to interact with the /etc/group file. In response to: >> tom lane >>Internet: tgl@cs.cmu.edu >>UUCP: <your favorite internet/arpanet gateway>!cs.cmu.edu!tgl >>BITNET: tgl%cs.cmu.edu@cmuccvma >>CompuServe: >internet:tgl@cs.cmu.edu >> >>I too have lost all confidence in SAM. My last straw was when I used SAM >>to add a new user, and it silently made gratuitous changes in other entries >>in /etc/passwd. I've forgotten the details, but I'm pretty sure that those ^^^^^^^^^^^^^^^^^^^^^^^^^^ >>changes created security holes. SAM uses the library calls getpwent(3C) (et al.) in a rather straightforward manner when modifying /etc/passwd. It is difficult (though not impossible) to see how arbitrary changes might be made to a properly formatted /etc/passwd file. If you can recall the details, that would be very helpful in determining what might be going on. >>If anybody at HP is listening, I suggest you either trash SAM or rewrite ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>it from the ground up. The first time somebody with a supposedly secure >>system gets bitten by something SAM did, you are looking at major trouble. We are listening and are receptive to your comments and concerns. That's why I solicit specifics and details, so that we can better address your needs. Rick Whitner rbw@hpfcla.hp.com hplabs!hpfcla!rbw Disclaimer - this posting represents my personal opinions only.
rml@hpfcdc.HP.COM (Bob Lenk) (07/07/90)
> >As such, a null password in the group file is not a security hole. It is > >equivalent to a star, except that a star will cause newgrp to prompt > >the user for a password when it will never match. > > I tried this, and found out that you are correct. I am glad to see that > such a gaping hole was not overlooked. Now, my next question, is why > was this behavior changed? To my (limited) knowledge, these semantics > are different from both Sys V and BSD derivative systems that I have > used. Was there a reason for this change, or was it gratuitous? These semantics are straight System V Release 2. I just looked at 7th Edition and see that there was a major change in between (though no corresponding change to the documentation). Presumably BSD releases prior to 4.2 (when they they dropped newgrp) are like version 7. I haven't checked other System V releases. > I DO hope these changes were made in setgid(2), rather than in newgrp(1). No, setgid(2) remains completely unaware of anything in the file system. To my knowledge only newgrp has ever known anything about the passwords in /etc/group. Bob Lenk rml@hpfcla.hp.com hplabs!hpfcla!rml
panguyen@vela.acs.oakland.edu (panguyen) (07/07/90)
I agree totally. I was talking to a Tech Support SE from HP who wrote the script in SAM. He admitted that there were some bugs within SAM. But when I ask him where are those bugs, he snowballed me at the end. Just FYI, the bug that I spotted was in adding new peripherals, particularly adding terminals and modems. When one use SAM, the entry in /etc/inittab will not be correct. At the same time, the device character file in /dev for the new terminal and / or modem will be screwed up, particularly in the minor number field. Just to let you guys know. Peter Nguyen
ses@hpfcdc.HP.COM (Steve Speer) (07/11/90)
/ hpfcdc:comp.sys.hp / panguyen@vela.acs.oakland.edu (panguyen) / 9:56 am Jul 7, 1990 / >I agree totally. I was talking to a Tech Support SE from HP who wrote >the script in SAM. >He admitted that there were some bugs within SAM. >But when I ask him where are those bugs, he snowballed me at the end. >Just FYI, the bug that I spotted was in adding new peripherals, >particularly adding terminals and modems. When one use SAM, the entry >in /etc/inittab will not be correct. At the same time, the device >character file in /dev for the new terminal and / or modem will be >screwed up, particularly in the minor number field. Just to let you >guys know. >Peter Nguyen >---------- The script for 7.0 sam (/usr/sam/bin/mkterm.sh) that creates the device files and puts the appropriate entry into /etc/inittab was not written by an S.E. This script was derived from a previous one (perhaps the one the SE was referring to), but the bug was introduced in support of modems on series 300 machines in 7.0. It ONLY creates the wrong device file if you are adding a modem (terminals are not affected) on a series 300 machine with a select code greater than 9. All other configurations create the correct device file. I am not aware of any problems with the entry in /etc/inittab, if you are, I would very much appreciate any details that you can offer. We are always concerned about any bugs that have made it out the door and want very much to identify them as quickly as possible to get them corrected as soon as possible. The defect in the shell script has been corrected for 8.0 and there is a very simple workaround/patch available to you. If you want to do it yourself, just edit the script above and move line #335 which looks like: lu=`echo $lu |awk '{printf("%x",$1)}'` to line #295 immediately after the comment: # remove old device and recreate That will fix it. Again, I'm not aware of any problems with the entry created in /etc/inittab (except that if you add a modem in the manner described above, the entry obviously won't function as intended). Any more details that can be offered for any bugs you've seen here will be greatly appreciated. Thank you, -Steven Speer Disclaimer: This note is posted as a courtesy and in no way represents any official postion or opinion of Hewlett-Packard. Any mistakes in the posting are the sole responsibility of myself.