From: Digestifier To: Linux-Admin@senator-bedfellow.mit.edu Reply-To: Linux-Admin@senator-bedfellow.mit.edu Date: Fri, 24 Sep 93 14:18:43 EDT Subject: Linux-Admin Digest #74 Linux-Admin Digest #74, Volume #1 Fri, 24 Sep 93 14:18:43 EDT Contents: Re: [Summary] /etc/shutdown by non-root (Fergus James HENDERSON) Re: [Summary] /etc/shutdown by non-root (Fergus James HENDERSON) Re: [Summary] /etc/shutdown by non-root (Fergus James HENDERSON) Re: Slackware series installation (Stefan Strecker) Re: [Not] enough SLS bashing (Greg Hennessy) Bug in Kernel.99pl12? (Quota) (Joerg Stenger) Re: security and Linux binaries (Malcolm Beattie) Re: How to use use 1.4MB 5 1/4 disk. Was: Not enough SLS bashing (Matt McLeod) Distributions that don't depend on media size (was: Re: [Not] enough SLS bashing) (Lars Wirzenius) Setting up "xdm" (Rick Miller) Re: Distributions that don't depend on media siz (Dave Safford) Re: Setting up "xdm" (Jack Coyote) SECURITY HOLE in SLS (anoyone can shutdown!) (Werner Gold) Re: SMAIL: problems with MXed sites in SLS (Gunther Anderson) ---------------------------------------------------------------------------- Crossposted-To: comp.unix.admin From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) Subject: Re: [Summary] /etc/shutdown by non-root Date: Fri, 24 Sep 1993 07:55:49 GMT In comp.os.linux.admin, someone writes: > This is on SunOS 4.1.2: Postings about SPARCS, SunOS, etc. are not really appropriate for comp.os.linux.admin, and tend to cause quite a bit of confusion over there. Can everyone please be careful to check the `Newsgroups:' line before following up? I'm sure that at least some of the articles in this thread were posted by people reading comp.unix.admin who didn't notice that it was cross-posted to comp.os.linux.admin. -- Fergus Henderson fjh@munta.cs.mu.OZ.AU ------------------------------ Crossposted-To: comp.unix.admin From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) Subject: Re: [Summary] /etc/shutdown by non-root Date: Fri, 24 Sep 1993 08:08:54 GMT jmc@pawnee.telecom.ksu.edu (James Chacon) writes: >josch@pc.chemie.th-darmstadt.de (Joachim Schnitter) writes: > >>Sorry to say that this seems to be real nonsense. A script is simply fed >>into a shell or another interpreter. It is the shell's permissions which >>counts - not the script's. > >Please get some information about this sort of situation before attempting >to spout off "fact". An excellent suggestion, one you should perhaps follow yourself :-) >A setuid shell script runs setuid, so does the shell that interprets it. It >can be spoofed very very easily. This is not correct - the correct answer is that it is system dependent. This whole issue is described in detail in comp.unix.questions FAQ #4.7 "How can I get setuid shell scripts to work?". Since this is cross-posted to comp.os.linux.admin, I should mention that Linux ignores setuid bits on shell scripts, although a I have a patch that implements _secure_ setuid shell scripts for Linux. -- Fergus Henderson fjh@munta.cs.mu.OZ.AU ------------------------------ Crossposted-To: comp.unix.admin From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) Subject: Re: [Summary] /etc/shutdown by non-root Date: Fri, 24 Sep 1993 08:21:51 GMT smd@floyd.brooks.af.mil (Sten Drescher) writes: >Animal# cat suidroot >#!/bin/sh >echo Hah! You\'re not root! [... and then shows how a cracker could exploit sh's -i option ...] > > Does this convince you that a suid root script, with any name, >can be used to become root, even if the shell that executes it is not >suid root? It convinces me that _that particular_ suid root script can be used to become root. But it doesn't convince me that _any_ suid root script can be used to become root. As with *all* setuid programs, you need to be careful, regardless of whether it is a shell script or a C program. The following C program would be just as insecure: main() { system("echo Hah! You're not root!"); } On the other hand, supposing that your operating system and shell support secure setuid scripts, then #!/bin/sh - /bin/echo Hah! You\'re not root! would be quite safe. -- Fergus Henderson fjh@munta.cs.mu.OZ.AU ------------------------------ From: strecker@goofy.zdv.Uni-Mainz.DE (Stefan Strecker) Subject: Re: Slackware series installation Date: 24 Sep 1993 08:33:49 GMT Hello Kenton, it should work with the command '/etc/pkgtool' (for Slackware 1.0.2). Maybe Patrick Volkerding should include this in one of his README* files, because there have been lots of those questions recently. Steve ------------------------------ From: gregh@cmkrnl.demon.co.uk (Greg Hennessy) Subject: Re: [Not] enough SLS bashing Reply-To: Gregh@cmkrnl.demon.co.uk Date: Fri, 24 Sep 1993 10:28:56 +0000 In article <1993Sep22.131709.6690@cc.gatech.edu> byron@cc.gatech.edu writes: >In article , >Scott Alfter wrote: >>In article <748617113snz@cmkrnl.demon.co.uk> gregh@cmkrnl.demon.co.uk (Greg > Hennessy) writes: >>>What planet those thise statement come from ? I have just showed this to a >>>friend of mine who is a OEM/VAR and I had to pick him up off the floor >>>laughing, His figures state that less than one in one-hundred new machines >>>shipping today come with a 5.25 drive let alone come configured to boot off >>>one. >> >>Say what? With the possible exception of IBM, I don't think there's >>anybody here in the US that ships systems with only 3.5" floppy >>drives. In mixed-drive systems, the 5.25" drive is almost always >>configured as the boot drive. >> >>I have the October issue of Computer Shopper in front of me. >>[ Machines with 5.25 boot disks descriptions deleted]. > >This is irrelavent in terms of the original argument (which this thread has >strayed away from). What I got from Greg's post is that most new machine have >a 1.44M 3.5" floppy. That's all you need to install Slackware. It doesn't >matter if it's the boot floppy or not. > >Let's kick the question out again: How many new machines are sold without >a 3.5" 1.44M floppy at all? > >BAJ >--- >Another random extraction from the mental bit stream of... >Byron A. Jeff - PhD student operating in parallel! >Georgia Tech, Atlanta GA 30332 Internet: byron@cc.gatech.edu > My sentiments exactly..... greg -- Greg Hennessy |Greg_Hennessy@europe.notes.pw.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|gregh@cmkrnl.demon.co.uk Nil aon tintean mar do thintean fein |gregh@cix.compulink.co.uk WRTC : Class of '91 |cmkrnl@cix.compulink.co.uk ZZ Top : They Really Can't Be Beat. |100065.225@compuserve.com ------------------------------ From: stenger@zeus.uni-duisburg.de (Joerg Stenger) Subject: Bug in Kernel.99pl12? (Quota) Date: 24 Sep 1993 11:11:43 GMT Reply-To: stenger@zeus.uni-duisburg.de Hi, I use the latest SLS1.03 distribution. Apart from many "bugs" caused from that distribution (i.e. wrong permissions, wrong net-setup, a SCSI-setup that didn't work for my configuration, lp-set, that doesn't work, etc) - I'll never use SLS again!!!- there seems to be a serious bug in the kernel. While making zImage (*with quota support enabled*) I get the following: --- begin make-zImage-log --- [...] quota gcc -D__KERNEL__ -Wall -Wstrict-prototypes -O6 -fomit-frame-pointer -x c++ -m486 -c dquot.c dquot.c: In function `int sync_device (struct device_list*, int)': dquot.c:330: warning: `fs' may be used uninitialized in this function dquot.c: In function `int quota_transfer (short unsigned int, short unsigned int, short unsigned int, short unsigned int, short unsigned int, long unsigned int, long unsigned int)': dquot.c:549: warning: `usr_device' may be used uninitialized in this function dquot.c:549: warning: `grp_device' may be used uninitialized in this function gcc -D__KERNEL__ -Wall -Wstrict-prototypes -O6 -fomit-frame-pointer -x c++ -m486 -c sys.c ld -r -o quota.o dquot.o sys.o [...] --- end make-zImage-log --- When I try to do a make quotacheck in /usr/src/quota I get a: gcc -I. -O6 -c quotacheck.c -o quotacheck.o In file included from /usr/include/linux/quota.h:117, from quotacheck.c:36: /usr/include/linux/fs.h:331: parse error before string constant /usr/include/linux/fs.h:342: parse error before string constant make: *** [quotacheck.o] Error 1 However make quotaon works. I have created a qouta.user with the quotacheck that came with SLS and when I tried to do a quotaon /dev/sda2 I got a: quotaon: using /home/helena/quota.user on /dev/sda2: Function not implemented when I did the same with the new-compiled quotaon from the source directory, my machine hang completely up. I got no "kernel panic", just a bunch of numbers: gerneral protection: 4930 EIP: 0010:00167C68 EFLAGS: 00010202 eax: 00186a60 ebx: 00ff0c00 ecx: 00004930 edx: 00186a60 esi: 00000000 ebi: 00000000 ebp: 001a4930 ds: 0018 es: 0018 fs: 002b gs: 002b PID: 1, process nr: 1 66 8e e1 bf 18 00 00 00 66 8e Has anybody any ideas? Should I use a different quota-package (would be typical for SLS, where almost nothing fits together)? If so, where? Thank You in advance for Your answers, and sorry for for the flames to SLS (not because of their content but they don't fit in this Newsgroup - I'm really upset!) Joerg Stenger ======================================================= E-Mail: stenger@zeus.uni-duisburg.de [134.91.4.79] or hj902st@unidui.uni-duisburg.de [134.91.4.3] ======================================================= ------------------------------ From: mbeattie@black.ox.ac.uk (Malcolm Beattie) Subject: Re: security and Linux binaries Date: Fri, 24 Sep 1993 12:12:38 GMT In article bogstad@blaze.cs.jhu.edu (Bill Bogstad) writes: > I agree with you in general; but binary distributions are not going >to go away. One thing that might help (a little) is if people who put >together packages would provide some kind of checksum of the package as a >whole. This would not only help to verify that the binary XWYSIWIG 2.0 >release that you just downloaded is clean (according to the original >packager); but would also help to quickly find the occassional corrupted >file that occurs. Since checksums are much smaller then whole packages; they >could be distributed through some other channel then binaries. This may >only work for the larger packages that have recognized authors; but it still >would be an improvement. Even better would be for the author or otherwise trusted person to make a list of checksums of the files in a package and then sign that list with PGP. That way, provided the checksum method is strong (and the checksums match :-) you can trust the package as much as you trust the author (or whoever PGP-signed the list). --Malcolm -- Malcolm Beattie | I'm not a kernel hacker Oxford University Computing Services | I'm a kernel hacker's mate 13 Banbury Road, Oxford, OX2 6NN (U.K.) | And I'm only hacking kernels Tel: +44 865 273232 Fax: +44 865 273275 | 'Cos the kernel hacker's late ------------------------------ From: matt@krikkit1.apana.org.au (Matt McLeod) Subject: Re: How to use use 1.4MB 5 1/4 disk. Was: Not enough SLS bashing Date: Thu, 23 Sep 1993 13:58:36 GMT KPARSONS@kentvm.kent.edu wrote: : You can easily use 1.44MB floppies if you only have a 5 1/4" drive. : Use the popular FDRORM18.ZIP package. With it you format your 1.2MB : floppies as 1.44MB. Then adjust the CMOS setup to tell it your 1.2 : drive is a 1.44. Then Linux will work with your 1.44 MB 5 1/4" : floppies. I didn't try this, but I told a friend with this problem : to do this, and he reported back to me that it works fine. So there : is no reason to have 1.2 MB versions. The other option of course is to use BOOT-B... So as long as you do actually have a 3.5" drive, it won't matter which size you want to boot from... Matt -- Matt McLeod Bob-Fearing Freelance Writer matt@krikkit1.apana.org.au ------------------------------ From: wirzeniu@kruuna.Helsinki.FI (Lars Wirzenius) Subject: Distributions that don't depend on media size (was: Re: [Not] enough SLS bashing) Date: 24 Sep 1993 16:44:34 +0300 byron@cc.gatech.edu (Byron A Jeff) writes: > Let's kick the question out again: How many new machines are sold without > a 3.5" 1.44M floppy at all? If I may, I'd like to ask a completely different question: Why are the distributions divided into floppy size bits and pieces in the first place? Or actually, I'd like to suggest that it would be better to have the distributions be independent of the media from which they are installed, be it a floppy of any size, tape, CD-ROM, nfs, or whatnot. This would require a program that would take the individual package files and put them onto floppies (or whatnot) in a suitable format. Existing tools include tar and cpio; the people (including me) working on the packaging tools need to address this problem as well. What I'd like, is a program to take the package files and write them to floppies, splitting files across floppies as necessary, and include some error correction bits so that floppy errors don't negate the whole thing (which almost happened to me when I tried Slackware). The program would need to run under both Linux and DOS (since many people need to get the files via a DOS machine, e.g., their DOS machine might be on a LAN, and their Linux machine not). -- Lars.Wirzenius@helsinki.fi (finger wirzeniu@klaava.helsinki.fi) It doesn't matter who you are, it's what you do that takes you far. --Madonna ------------------------------ From: rick@ee.uwm.edu (Rick Miller) Subject: Setting up "xdm" Date: 24 Sep 1993 14:52:39 GMT Okay... Thanks to all the folks who responded to my last question, but no: It doesn't appear to be a permissions problem. All the X executables *are* globally readable and executable, and some (like the X, XF86_*, and xterm) are properly setuid-root'd. Here's a bit more detail on my problem: User Got into X by: Symptoms ---- -------------- -------- root "startx" from bash Works great! root xdm Seems to work, BUT "more" is strange.** rick either xdm or startx Everything EXCEPT the "xterm" comes up,*** and "more" is strange.** ** by '"more" is strange', I mean that whenever I attempt to "more" a file more than 24 lines long, I see the first 24 lines, then more EXITS. *** "xterm" was complaining that it couldn't find "//libXaw.so.3", so I managed to get the xterm to come up (if I recall correctly) by manually defining LD_LIBRARY_PATH=/lib:/usr/lib:/usr/X386/lib in several places. RICK MILLER Voice: +1 414 221-3403 P.O. BOX 1759 FAX: +1 414 221-4744 MILWAUKEE, WI Send a postcard and I'll send one back. 53150-1759 USA Sendu bildkarton kaj mi retrosendos unu. ------------------------------ From: d-safford@tamu.edu (Dave Safford) Subject: Re: Distributions that don't depend on media siz Date: 24 Sep 1993 14:51:22 GMT Reply-To: d-safford@tamu.edu In article eps@kruuna.Helsinki.FI, wirzeniu@kruuna.Helsinki.FI (Lars Wirzenius) writes: >** by '"more" is strange', I mean that whenever I attempt to "more" a >file more than 24 lines long, I see the first 24 lines, then more EXITS. use 'less' instead. It works fine. -- No, really. I'm not a policeman, I'm an astrophysicist. -- Liquid Sky ------------------------------ From: gold@wpfx01.physik.uni-wuerzburg.de (Werner Gold) Subject: SECURITY HOLE in SLS (anoyone can shutdown!) Date: 24 Sep 1993 16:52:25 GMT If you want to shutdown any Linux machine based on SLS try: rsh -l root /etc/halt ^^^^^^^^ or anything else !!! Do that from any host you like. This works on the default setting of "passwd". When root sets up a password no asterisk is added to the second column of passwd. Even though I had a root password and a shadow entry the passwd entry looked like this: root::0:0::/root:/bin/sh I think the passwd executable should check the contents of the second column and add an asterisk automatically. (I dont know who writes the shadow routines - please think about it) Peter is not to blame for that, because the missing entry is neccessary for making the installation without a root-password. This might be a stupid U*ix problem that anyone who read any sysadmin book should know, but how many machines are out there with a passwd entry like above... Werner ------------------------------ From: gunther@ssi.edc.org (Gunther Anderson) Subject: Re: SMAIL: problems with MXed sites in SLS Date: Fri, 24 Sep 1993 17:17:13 GMT Michael 'Moose' Dinn (dinn@ug.cs.dal.ca) wrote: : smail doesn't seem to want to send mail to sites with only MX records and no : "real" IP addresses. : Anyone else find this problem, or have a fix? Well, that depends on what exactly you're talking about. Error messages would be a nice addition to your posting. Context of MX records might help too. Testy snipping aside, though, I recently added a few MX records here, and went out to test them, and nothing seemed to work. No one had ever heard of these new sites. What I had forgotten was that other sites sometimes use the secondaries, which wouldn't be getting my revised tables for some appreciable time lag. I think maybe 1000 seconds or so. So that might simply be your case. But smail I'm pretty sure was written to hunt MX records first, and then only fall back to the real address. So after 20 minutes, the other machines all started to find my new records, and mail went through properly. Just trying to help, Gunther ------------------------------ ** 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 ******************************