From: Digestifier To: Linux-Admin@senator-bedfellow.mit.edu Reply-To: Linux-Admin@senator-bedfellow.mit.edu Date: Sat, 4 Sep 93 18:13:20 EDT Subject: Linux-Admin Digest #35 Linux-Admin Digest #35, Volume #1 Sat, 4 Sep 93 18:13:20 EDT Contents: Re: Long shadow passwords less secure than normal ones? (Larry Doolittle) Re: Long shadow passwords less secure than normal ones? (Jason Haar) Re: Long shadow passwords less secure than normal ones? (Frank Lofaro) Re: Long shadow passwords less secure than normal ones? (Jason Haar) Public Domain driver for SMC Ethernet card (Mike Stein) Re: XDM bug/Shadow passwords. (Daniel T. Schwager) [Q] Description of Linux startup sequence (Eugene Kim) Re: [Q] Description of Linux startup sequence (Stephen Harris) Re: [Q] Description of Linux startup sequence (Drew Eckhardt) Re: Long shadow passwords less secure than normal ones? (Ralph Doncaster) Re: [Q]: eliminating hostname before 'login:' with MCC (Pat Mackinlay) mt: /dev/tape not found? (qic-02) (Sait Umar,) Looking for fsck-at-boot utility (Eric J. Schwertfeger) Re: [Q]: eliminating hostname before 'login:' with MCC (Philippe Steindl) Re: Let's collect KNOWN BUGS (Patrick J. Volkerding) building kernel WITHOUT sound support (Bill Heiser) ---------------------------------------------------------------------------- From: doolitt@cebaf4.cebaf.gov (Larry Doolittle) Subject: Re: Long shadow passwords less secure than normal ones? Reply-To: doolitt@cebaf4.cebaf.gov (Larry Doolittle) Date: Fri, 3 Sep 1993 16:54:27 GMT In article , tem1@Isis.MsState.Edu (Tim Miller) writes: > > If I remeber the purpose of shadow passwords correctly, the shadow > password file is root read only (the regular passwd file is still > there, but passwords are in separate file). No one else could read it. So, > unless someone makes the blatant goof of making it world readable, > there should be no problem. No one could get the file to crack it. ^^^^^^ Better to say "not everybody and his brother" could get the file. Overall *nix security is not the greatest, nor is it intended to be. It is relevant to plug as many of the easy holes as possible, like with shadow passwords. Do you ever log in as root (even with "su" from a real account) over the net? If so, your password goes unencrypted over the ethernet for all with a network analyzer to read. - Larry Doolittle doolittle@cebaf.gov ------------------------------ From: Jason Haar Subject: Re: Long shadow passwords less secure than normal ones? Date: Sat, 4 Sep 1993 00:29:59 GMT In article Larry Doolittle (doolitt@cebaf4.cebaf.gov) wrote: > Do you ever log in as root (even with "su" from a real account) over > the net? If so, your password goes unencrypted over the ethernet > for all with a network analyzer to read. Yeah - just like it does under DECnet and LAT too... Basically most terminal-based logins send passwords in the clear... -- Cheers Jason Haar, Network Consultant ------------------------------ From: ftlofaro@unlv.edu (Frank Lofaro) Subject: Re: Long shadow passwords less secure than normal ones? Date: Sat, 4 Sep 93 01:12:44 GMT In article Jason Haar writes: >In article Larry Doolittle (doolitt@cebaf4.cebaf.gov) wrote: > >> Do you ever log in as root (even with "su" from a real account) over >> the net? If so, your password goes unencrypted over the ethernet >> for all with a network analyzer to read. > >Yeah - just like it does under DECnet and LAT too... > >Basically most terminal-based logins send passwords in the clear... > > Some telnet's and telnetd's support encryption, perhaps this would be good to get for linux... ------------------------------ From: Jason Haar Subject: Re: Long shadow passwords less secure than normal ones? Date: Sat, 4 Sep 1993 02:01:33 GMT In article <1993Sep4.011244.22069@unlv.edu> Frank Lofaro (ftlofaro@unlv.edu) wrote: > Some telnet's and telnetd's support encryption, perhaps this would > be good to get for linux... Sure! But that assumes you can find the clients that will interoperate with it... I am sure it will happen - the industry can't afford to carry on with such a glaring hole (even though it doesn't seem to be exploited too much...) -- Cheers Jason Haar, Network Consultant ------------------------------ From: mikes@hgc.edu (Mike Stein) Subject: Public Domain driver for SMC Ethernet card Date: Fri, 3 Sep 1993 18:43:24 GMT Are there any Public Domain drivers for the SMC3016 Ethernet card. What ftp sites are there for Public Domain drivers? Mike Stein Hartford Graduate Center ------------------------------ From: danny@dragon.stgt.sub.org (Daniel T. Schwager) Subject: Re: XDM bug/Shadow passwords. Date: Thu, 2 Sep 1993 18:14:14 GMT Geir Harris Hedemark (geirhe@ifi.uio.no) wrote: : Has anyone with the knowledge to hack the source for xdm noticed that it : never takes a look at the shadow password file? I am using Xfree86-1.3 : from sunsite.unc.edu. Or maybe someone has fixed this already? :-) Download the shadow-version of xdm from sunsite or tsx. Danny -- ,,, (^ ^) ==================oOO==(_)==OOo======================= Danny ------------------------------ Subject: [Q] Description of Linux startup sequence From: eekim@husc11.harvard.edu (Eugene Kim) Date: 3 Sep 93 23:31:00 EDT The startup sequence for DOS is fairly straightforward (*.SYS;shell; autoexec.bat). Could some kind soul describe to me in detail the Linux startup routine? How similar is this routine to other UNIX, and how flexible is it? If there's a doc for this, could someone direct me to it? I've read the alpha SAG, but it doesn't have any mention of this. Maybe it should. -- . Eugene Eric Kim ......................................................... . eekim@husc.harvard.edu .................................................. . "Dangerous stuff, science. Lots of us not fit for it." .. ........................................ -H.C. Bailey, "The Long Dinner" .. ------------------------------ From: harris@teaching.physics.ox.ac.uk (Stephen Harris) Subject: Re: [Q] Description of Linux startup sequence Date: 4 Sep 93 11:07:32 BST Eugene Kim (eekim@husc11.harvard.edu) wrote: : The startup sequence for DOS is fairly straightforward (*.SYS;shell; : autoexec.bat). Could some kind soul describe to me in detail the : Linux startup routine? How similar is this routine to other UNIX, : and how flexible is it? Well, Linux is a little harder, depending on how you boot it! For example, I boot via DOS, MBOOT and BOOTLIN, so I have the standard BIOS startup, which calls MBOOT, which juggles my autoexec/config files around, which calls DOS, which calls a shell a BOOTLIN which loads the kernel, which calls the TurboBoot routines, which runs the kernel. If you use LILO, I suggest you read the LILO manuals. After the kernel has started, it then needs to start the user level code. It tries to run /etc/init, and if it can't find that, various other programs, ending the sequence in /bin/sh. I think the code is in something like main/init.c (my Linux machine isn't booted at present, so I can't check). Its pretty straight forward. And also flexible enough that a "emergency" disk simply needs a /bin/sh on it to keep the kernel happy! No init overhead or anything like that. -- Stephen Harris harris@teaching.physics.ox.ac.uk Opinions are just opinions, and the facts are the facts. But what are what? ------------------------------ From: drew@kinglear.cs.colorado.edu (Drew Eckhardt) Subject: Re: [Q] Description of Linux startup sequence Date: Sat, 4 Sep 1993 12:10:21 GMT In article <1993Sep3.233100.28120@husc14.harvard.edu> eekim@husc11.harvard.edu (Eugene Kim) writes: >The startup sequence for DOS is fairly straightforward (*.SYS;shell; >autoexec.bat). Could some kind soul describe to me in detail the >Linux startup routine? Some bootstrap program (LILO or Shoelace) reads an image into memory. Code then kicks the processor into protected mode, and in recent releases a decompressor runs on compressed data before executing it. The kernel starts up, does various device initializations, and forks a process (init). PID 1 tries to run /etc/init, /bin/init,or /sbin/init, those failing it runs /etc/rc followed by a root shell. It loops when these things die. init runs /etc/rc which fscks filesystems, starts various daemons, etc. /etc/rc generally runs /etc/rc.local. On completion, init starts getty processes on the ports its been told to, and the system is up in multiuser. Some inits will take a command line switch to invoke a single user mode. >How similar is this routine to other UNIX Other unices allways assume that /etc/init will run, otherwise it's very similar. >and how flexible is it? A lot of things are started out of /etc/rc, /etc/rc.local. These are usually Bourne shell scripts, so they're highly configurable. -- Boycott USL/Novell for their absurd anti-BSDI lawsuit. | Drew Eckhardt, Condemn Colorado for Amendment Two. | Profesional Linux Use Linux, the fast, flexible, and free 386 unix | Consultant Will administer Unix for food | drew@cs.Colorado.EDU ------------------------------ From: rdoncast@bcoc61.on.bell.ca (Ralph Doncaster) Subject: Re: Long shadow passwords less secure than normal ones? Reply-To: rdoncast@yo_dud Date: Fri, 3 Sep 1993 16:22:56 GMT In article <1993Sep2.204255.28773@umibox.hanse.de> root@umibox.hanse.de (Bernd Meyer) writes: Hi, I recently looked through the source of the shadow-packet and discovered that, given a password longer than 8 characters, the routine pw_encrypt simply splits it into two parts, one being the first 8 characters, the other being the rest. These get encrypted separatly, and the result is stored separatly. This looks like an invitation for a security hole to me - most people (me included) tend to think "A long password is a good password". And, as we all know, a password should containn some punctuation and some non-letters. Now lets say I take "RecEiver:9@" as my password. This will be an easy one for Crack. One part that is encrypted is just some variation of "receiver", the other one is only three characters long. So the long passwords in the current shadow implementation look more like two passwords to Crack, one of which can probably broken by brute force (even the second part of a 13 character password could be found within a couple of hours), the other one probably less obscured by digits/punctuation than a standard one. My advice for system administrators thus seems to be: "Either force your users to use REALLY long words and make sure that they know the way the passwords are encrypted, or recompile the shadow stuff without the option for long passwords enabled." Bernie Since the passwords are shadowed, assuming there are no other gaping security holes in the system, then they would never be able to read the encrypted passwords anyway. If they can read the shadowed passwords, then they most likely already have root privileges, so it's game over. -Ralph -- Ralph Doncaster, computer consultant Bell Sygma Telecomm Solutions home email: ralph@dci.pinetree.org ph:(613)781-6774 fax:781-7677 " my other computer is a Cray-3 " email: rdoncast@on.bell.ca ------------------------------ From: mackinla@cs.curtin.edu.au (Pat Mackinlay) Subject: Re: [Q]: eliminating hostname before 'login:' with MCC Date: 4 Sep 93 16:39:37 GMT qpliu@ernie.Princeton.EDU (Quowong P. Liu) writes: >In article mackinla@cs.curtin.edu.au (Pat Mackinlay) writes: >>roland@cac.washington.edu (Liem Bahneman) writes: >>>How do I eliminate the 'hostname login:' and restore to just 'login:' on >>>incoming telnet connections? >>After a brief look at the source to the MCC distribution's getty (agetty), >>I can say that you can't get rid of the hostname without recompiling the >>source. Fair enough? >Enough misinfomation on this triviality. telnetd doesn't touch getty. >You need to recompile login, which has been printing the hostname >since the 0.12 days. Well _sorry_! I admit, I did not read the question as accurately as I should have. You're correct that telnetd does not use getty and that login itself must be hacked here. It's also true, however, that for "regular" console logins, the getty does the username prompting and must be hacked to remove the message for local tty logins. -- Pat -- "There's only one thing left to do Mama, I got to ding a ding dang my dang a long ling long" (Jesus Built My Hotrod -- Ministry) GCS d* -p+ c++ l++ m--- s+/- !g w- t- r ------------------------------ From: umar@compsci.cas.vanderbilt.edu (Sait Umar,) Subject: mt: /dev/tape not found? (qic-02) Date: Sat, 4 Sep 1993 17:51:11 GMT I bought a WANGTEK 5150PK tape drive which is QIC-02 compatible. The host adapter switch settings are at (I/O=0x338,DMA=3,IRQ=2 in tpqic02.c file). I recompiled the kernel with tpqic02.c having the same values as the switch settings (otherwise it conflicts with 3c503 card). The boot process detects and gives the message that tpqic02 at I/O=338, DMA=3, IRQ=2.... The Major device number in tpqic02.h is 12. I am not sure about how to find the minor numbers. I created the devices as required by the tpqic02 manual. Specifically, I created mknod /dev/tape c 12 8 for QIC-150 dev. Then I try to use mt to test the tape by simly issuing mt rewind the response is mt: cannot find /dev/tape or /dev/tape doesn't exist, something like that. I used the -f option, tried different tape devices to no avail. When I insert a tape into the tape drive the drive automatically rewinds, so at least I know it is on! What could be wrong? I have the version of the driver that came with SLS 1.03, seems to be pretty new. Thanks, -- ========================================================================= umar@compsci.cas.vanderbilt.edu Prof.A.S. Umar umarsa00@vuctrvax.bitnet Department of Physics & Astronomy Tel: (615) 322-2459 Vanderbilt University Fax: (615) 343-7263 Nashville, TN 37235 ========================================================================= ------------------------------ From: maniac@unlv.edu (Eric J. Schwertfeger) Subject: Looking for fsck-at-boot utility Date: Sat, 4 Sep 93 17:45:22 GMT I know someone has a package that patches the kernel so that it can unmount the root partition (remounting it in read-only mode), and I'd like to find this, as I'm playing around with a device driver and want to ensure that my root partition isn't getting affected. One unrelated question, does shutdown call fsync()? -- Eric J. Schwertfeger, maniac@cs.unlv.edu ------------------------------ From: ilg@imp.ch (Philippe Steindl) Subject: Re: [Q]: eliminating hostname before 'login:' with MCC Date: 4 Sep 1993 21:16:48 +0200 Hia, well .. this is not a "system feature", it depends on what shell you are using. If you use bash, try PS1='[`whoami`] `pwd`>' or anything similar. Put this line in /etc/profile. With tcsh 6.04, try set prompt="[`whoami`] %~%#" or similar. cu then! Philippe PS: hum, why does /etc/profile not get sourced with MCC when logging in as root? ------------------------------ From: bf703@cleveland.Freenet.Edu (Patrick J. Volkerding) Subject: Re: Let's collect KNOWN BUGS Date: 4 Sep 1993 20:26:39 GMT Reply-To: bf703@cleveland.Freenet.Edu (Patrick J. Volkerding) In a previous article, kai@depeche.toppoint.de (Kai Voigt) says: >I don't think that a newsgroup would be necessary. We collect the bugs >and post them frequently in a single list to c.o.l.announce, who wants >to contribute bugs or anything that might be improved in the SLS, >should send a report about it to me. But, aren't there already enough bugs in SLS? ;^) Seriously, after seeing posts about the same SLS bugs over and over again, I tend to doubt this will really help do anything about them at the source. (where it counts) I think if SLS is going to continue to try to lead the way, someone in change of it should get a *usable email address* and start taking bug reports a little more seriously. The solution on the user end is to switch to a better distribution, if the problems with SLS cannot be resolved. My Slackware distribution has far fewer bugs, and comes with a full collection of software, including X11. The MCC distribution doesn't come with all the bells and whistles, but it's about as bug free as a distribution can get. Everything I hear about the ongoing Debian project suggests that it will be far superior to SLS and may become the leading package in the not too distant future. Consider your options! -- Patrick Volkerding volkerdi@mhd1.moorhead.msus.edu bf703@cleveland.freenet.edu ------------------------------ From: heiser@bumetb.bu.edu (Bill Heiser) Subject: building kernel WITHOUT sound support Date: 4 Sep 1993 20:21:29 GMT Reply-To: heiser@bumetb.bu.edu (Bill Heiser) When I run "make config", and answer NO to all of the sound-board-related questions, and then run "make dep", the make complains about not having a sound driver enabled. How do I build a kernel without any support for sound drivers? Thanks Bill ------------------------------ ** FOR YOUR REFERENCE ** The service address, to which questions about the list itself and requests to be added to or deleted from it should be directed, is: Internet: Linux-Admin-Request@NEWS-DIGESTS.MIT.EDU You can send mail to the entire list (and comp.os.linux.admin) via: Internet: Linux-Admin@NEWS-DIGESTS.MIT.EDU Linux may be obtained via one of these FTP sites: nic.funet.fi pub/OS/Linux tsx-11.mit.edu pub/linux sunsite.unc.edu pub/Linux End of Linux-Admin Digest ******************************