On a linux box working as PPP server / router / firewall, I wish to
spindown the HD for long period of inactivity. But some programs (mgetty)
needs to periodically create lock files (in order to test modems). I''ve
set up thinks like this :
-created a /var/lock.skel dir, containing the directory structure of
/var/lock (emacs seems to need its own subdir)
-at startup, create a ramdisk on mount it on /var/lock :
#create a small ramdisk, mount /var/lock there
dd if=/dev/zero of=/dev/ram15 bs=1k count=64 > /dev/null
mke2fs -m0 /dev/ram15 64 > /dev/null
mount /dev/ram15 /var/lock > /dev/null
cp -raf /var/lock.skel/* /var/lock/ >/dev/null
This way, creating a log file will not spinup the HD. Added benefit is
that there won''t be stale locks after power failure...
How safe is it to have things set up this way ? Does it create some
security problems ?
Thanks in advance
Pascal A. Dupuis
--
Q: How many existentialists does it take to screw in a lightbulb?
A: Two. One to screw it in and one to observe how the lightbulb
itself symbolizes a single incandescent beacon of subjective
reality in a netherworld of endless absurdity reaching out
toward a maudlin cosmos of nothingness.
Rogier Wolff
1996-Nov-21 08:49 UTC
Re: BOUNCE: Re: [linux-security] Chattr +i and securelevel
Alexander O. Yuriev wrote:> > Your message dated: Wed, 20 Nov 1996 18:04:39 EST > > >has anyone played with the securelevel variable in the kernel and the > > >immutable flags in the ext2 file system? > > > > Yes, and its actualy quite nice. > > > > >The sysctrl code seems to allow the setting of the flag > > >only by init (PID=1) and only upwards (0->1, etc). > > >[ Mod: If you have a look at securelevel code you can see that at this > > >moment the only process that can change securelevel is init. > > > > Look closer. It''s an exported symbol that any module can link > > against (and alter?). > > Lets not even talk about modules - modules are running in a kernel mode > which means that they can violate any and all privs. > > > To be honest, I haven''t gone through the trouble > > of coding a module yet, but compiled kernels with securelevel=1 works. :) > > It''s a nice lock+key function when you''re looking to immute or append- > > only special files. (Immuting /etc/passwd on production machines is a > > simple security measure that saves hours of time... trust me.) > > Which will prevent passwd, chfn and chsh work.... So no, I won''t trust you. > > > I did, > > however, notice a couple of broken things in the immutable area, namely, > > the execption for root is tested before the immutable kick-out code. > > The main reason I use the immute/append tags are so processes running > > as root CANT alter certain files. (Ie a human has to un-tag the files > > before they can be altered). > > Correct me if I am wrong but is not chattr a wrapper against a system call? > Who will prevent a program running as root to issue such call? Essentially, > I think we can agree that there is no way to prevent a smart attacker from > penetrating a system, you can only make your system harder to penetrate than > a system of your neighbour.The securelevel code simply isn''t finished. I suspect Remi Card had the feeling he wanted a securelevel variable, stuck it in in his area of the code (ext2fs) and put in a little code in the sysctl as an example of how this variable might be changed. When securelevel <> 0, you should 1) Disable writing/reading block devices. (i.e. you can no longer use mtools for floppies) 2) disable writing/reading char devices, except maybe mouse and serial ports. (At least kmem should be disabled, which is a char device.) 3) Disable module loading. 4) disable the chattr call for ext2fs. Only (4) is implemented right now. Roger.> > Best wishes, > Alex >From mail@mail.redhat.com 11628 by invoked 501); uid Received: (qmail 17521 invoked from network); 22 Nov 1996 21:43:54 -0000 Received: from bach.cis.temple.edu (155.247.71.92) by mail2.redhat.com with SMTP; 22 Nov 1996 21:43:53 -0000 Received: (from alex@localhost) by bach.cis.temple.edu (8.7.4/8.7.3) id QAA22951; Fri, 22 Nov 1996 16:56:41 -0500 Received: from mail2.redhat.com (mail2.redhat.com [199.183.24.247]) by bach.cis.temple.edu (8.7.4/8.7.3) with SMTP id QAA22935 for <alex@bach.cis.temple.edu>; Fri, 22 Nov 1996 16:53:12 -0500 Received: (qmail 11628 invoked by uid 501); 22 Nov 1996 21:38:21 -0000 Received: (qmail 11472 invoked from network); 22 Nov 1996 21:38:13 -0000 Received: from bach.cis.temple.edu (155.247.71.92) by mail2.redhat.com with SMTP; 22 Nov 1996 21:38:12 -0000 Received: from bach.cis.temple.edu (localhost [127.0.0.1]) by bach.cis.temple.edu (8.7.4/8.7.3) with ESMTP id QAA22923; Fri, 22 Nov 1996 16:50:59 -0500 Message-Id: <199611222150.QAA22923@bach.cis.temple.edu> To: linux-security@redhat.com cc: linux-alert@redhat.com Subject: LSF Update#14: Vulnerability of the lpr program. Date: Fri, 22 Nov 1996 16:50:57 -0500 From: "Alexander O. Yuriev" <alex@bach.cis.temple.edu> Approved: alex@bach.cis.temple.edu -----BEGIN PGP SIGNED MESSAGE----- $Id: lpr-vulnerability-0.6-linux,v 1.1 1996/11/22 21:42:46 alex Exp $ Linux Security FAQ Update lpr Vulnerability Thu Nov 21 22:24:12 EST 1996 Copyright (C) 1995,1996 Alexander O. Yuriev (alex@bach.cis.temple.edu) CIS Laboratories TEMPLE UNIVERSITY U.S.A. ============================================================================ This is an official Update of the Linux Security FAQ, and it is supposed to be signed by one of the following PGP keys: 1024/ADF3EE95 1995/06/08 Linux Security FAQ Primary Key <Alexander O. Yuriev> Unless you are able to verify at least one of signatures, please be very careful when following instructions. Linux Security WWW: http://bach.cis.temple.edu/linux/linux-security linux-security & linux-alert mailing list archives: ftp://linux.nrao.edu/pub/linux/security/list-archive ============================================================================ REVISION HISTORY (This section in automatically maintained by the Revision Control System ) $Log: lpr-vulnerability-0.6-linux,v $ Revision 1.1 1996/11/22 21:42:46 alex Initial revision ABSTRACT A vulnerability exists in the lpr program version 0.06. If installed suid to root, the lpr program allows local users to gain access to a super-user account. RISK ASSESSMENT Local users can gain root privileges. The exploits that exercise this vulnerability were made available. VULNERABILITY ANALYSIS lpr utility from the lpr 0.06 suffers from the buffer overrun problem. Installing lpr as a suid-to-root is needed to allow print spooling. DISTRIBUTION FIXES Red Hat Commercial Linux RedHat 2.1, RedHat 3.0.3 (Picasso) and RedHat 4.0 contain vulnerable lpr utility. Users of RedHat Linux distributions prior to version 4.0 are urged to upgrade to RedHat Linux 4.0 The replacement RPMS are available from the following URLs: RedHat 4.0 x86 Architecture ftp://ftp.redhat.com/pub/redhat/redhat-4.0/updates/i386/lpr-0.12-1.i386.rpm ftp://bach.cis.temple.edu/pub/Linux/Security/DISTRIBUTION-FIXES/RedHat/lpr-0.12-1.i386.rpm RedHat 4.0 Alpha Architecture ftp://ftp.redhat.com/pub/redhat/redhat-4.0/updates/axp/lpr-0.12-1.axp.rpm ftp://bach.cis.temple.edu/pub/Linux/Security/DISTRIBUTION-FIXES/RedHat/lpr-0.12-1.axp.rpm RedHat 4.0 SPARC Architecture ftp://ftp.redhat.com/pub/redhat/redhat-4.0/updates/sparc/lpr-0.12-1.sparc.rpm ftp://bach.cis.temple.edu/pub/Linux/Security/DISTRIBUTION-FIXES/RedHat/lpr-0.12-1.sparc.rpm Please verify the MD5 fingerprint of the RPMs prior to installing them. 6d36461d6c8b6c50ccadf9de530a6136 lpr-0.12-1.i386.rpm 87eb9c5b4d7e6a4217fdb9d3bbd6527b lpr-0.12-1.axp.rpm c04359e61cd16108ce5793aa388f206f lpr-0.12-1.sparc.rpm Caldera Network Desktop Caldera Network Desktop version 1.0 contains a vulnerable lpr program. The replacement RPMS are available from the following URLs: ftp://ftp.caldera.com/pub/cnd-1.0/updates/NetKit-B-lpr-0.06-4c2.i386.rpm ftp://bach.cis.temple.edu/pub/Linux/Security/DISTRIBUTION-FIXES/CND/NetKit-B-lpr-0.06-4c2.i386.rpm WARNING: We are unable to provide the MD5 fingerprint for the replacement kit from Caldea as it was not provided to us. Debian Debian/GNU Linux 1.1 does not use lpr program and therefore is not vulnerable. If you have installed lpr package yourself, your system becomes vulnerable. Slackware There is no official information available about vulnerability of Slackware 3.0 or Slackware 3.1 distributions from distribution maintainer. The testing indicates that both Slackware 3.0 and Slackware 3.1 distributions contains the vulnerable lpr program. Until the official fix-kit for Slackware 3.0 and Slackware 3.1 available system administrators are advised to follow the instructions in the Other Linux Distributions section of this LSF Update. Yggdrasil Yggdrasil Computing Inc neither confirmed not denied vulnerability of Plug and Play Fall''95 Linux. The testing indicates that Plug and Play Fall''95 Linux distribution contains a vulnerable lpr. Until the official fix-kit for Yggdrasil Plug and Play Linux becomes available system administrators are advised to follow the instructions in the Other Linux Distributions section of this LSF Update Other Linux Distributions It is believed at this moment that all Linux distributions using lpr version 0.06 or prior contain a vulnerable lpr program. Administrators of systems based on distributions not listed in this update or distributions that do not have fix-kits available at the moment are urged to contact their support centers requesting the fix-kits to be made available to them. In order to prevent the vulnerability from being exploited in the mean time, it is recommended that the suid bit is removed from the lpr program using command chmod u-s /usr/bin/lpr Until the official fix-kits are available for those systems, it is advised that system administrators obtain the source code of a LPRng print system used in Debian/GNU Linux 1.1, compile it and replace the lpr subsystem. ftp://ftp.debian.org/debian/project/experimental/lprng_2.3.12.orig.tar.gz ftp://ftp.debian.org/debian/project/experimental/lprng_2.3.12-2.diff.gz ftp://bach.cis.temple.edu/pub/Linux/Security/DISTRIBUTION-FIXES/OTHER/lprng_2.3.12.orig.tar.gz ftp://bach.cis.temple.edu/pub/Linux/Security/DISTRIBUTION-FIXES/OTHER/lprng_2.3.12-2.diff.gz Please verify the MD5 fingerprint of the files prior to installing them. ca51aaa4560ddfc6ced987d568d8cc1c lprng_2.3.12-2.diff.gz f1c23e214a752e1c2dab2399b3457d2d lprng_2.3.12.orig.tar.gz CREDITS This LSF Update is based on the information originally posted to linux-security mailing list. The information on the fix-kit for Red Hat commercial Linux was provided by Marc Ewing (marc@redhat.com) of Red Hat Software Inc,; for the Caldera Network Desktop by Ron Holt of Caldera Inc.; for Debian/GNU Linux 1.1 by Sven Rudolph <sr1@inf.tu-dresden.de> of Debian Project. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMpYbw4xFUz2t8+6VAQF9pgQAhwl4zNBrlfVxgv7+Ubm8uRkRRaZcjvxH 4F4FdFdtBjyqgkj4dMIKEEhy28TZbAqh0ks6eiviwFAYuMnu3G+MBeGLyHOpX4Mw krb7At3wt41Yj5NXHpsz9GebYBVfM8sOl4CKX0UcdXdizxfNKxXd8SJLnYteye2b 8paVHnyyDyo=9xvg -----END PGP SIGNATURE----- From mail@mail.redhat.com mail2.redhat.com dutecai.et.tudelft.nl by (8.6.10/1.34JP) Received: (qmail 28417 invoked from network); 24 Nov 1996 14:32:27 -0000 Received: from rosie.et.tudelft.nl (130.161.127.248) by mail2.redhat.com with SMTP; 24 Nov 1996 14:32:25 -0000 Received: from cave.et.tudelft.nl (cave.et.tudelft.nl [130.161.127.241]) by rosie.et.tudelft.nl (8.7.4/8.7.3) with ESMTP id LAA22887; Sun, 24 Nov 1996 11:36:04 +0100 Received: (from wolff@localhost) by cave.et.tudelft.nl (8.7.6/8.7.3) id LAA00487; Sun, 24 Nov 1996 11:39:04 +0100 Received: from mail2.redhat.com by dutecai.et.tudelft.nl (8.6.10/1.34JP) id DAA08412; Fri, 22 Nov 1996 03:08:43 +0100 Received: (qmail 11698 invoked by uid 501); 22 Nov 1996 02:08:56 -0000 Received: (qmail 11686 invoked from network); 22 Nov 1996 02:08:52 -0000 Received: from redhat.com (root@199.183.24.1) by mail2.redhat.com with SMTP; 22 Nov 1996 02:08:52 -0000 Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by redhat.com (8.7.4/8.7.3) with SMTP id VAA24691 for <linux-security@redhat.com>; Thu, 21 Nov 1996 21:08:17 -0500 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <16096(4)>; Thu, 21 Nov 1996 17:33:09 PST Received: by crevenia.parc.xerox.com id <177557>; Thu, 21 Nov 1996 17:27:06 -0800 From: Bill Fenner <fenner@parc.xerox.com> Approved: R.E.Wolff@BitWizard.nl To: alan@cymru.net Subject: Re: About DNS again Cc: linux-security@redhat.com Message-Id: <96Nov21.172706pst.177557@crevenia.parc.xerox.com> Date: Thu, 21 Nov 1996 17:27:04 PST Status: RO>Also if you remember I moaned at someone [Bill Fenner I think] on here who >posted a big ping program that assumed the resolver gave back good lengths >and got a reply saying I was talking crap.. now you know why I said it.You''re right. I should never have released a program that I originally wrote for a limited audience, and for that, I apologize. (The resolver library on the system on which I wrote the program did not have that bug). Bill From mail@mail.redhat.com relay2.redhat.com dutecai.et.tudelft.nl by (8.6.10/1.34JP) Received: (qmail 29710 invoked from network); 24 Nov 1996 14:34:43 -0000 Received: from rosie.et.tudelft.nl (130.161.127.248) by mail2.redhat.com with SMTP; 24 Nov 1996 14:34:41 -0000 Received: from cave.et.tudelft.nl (cave.et.tudelft.nl [130.161.127.241]) by rosie.et.tudelft.nl (8.7.4/8.7.3) with ESMTP id LAA22880 for <linux-security@redhat.com>; Sun, 24 Nov 1996 11:34:32 +0100 Received: (from wolff@localhost) by cave.et.tudelft.nl (8.7.6/8.7.3) id LAA00431; Sun, 24 Nov 1996 11:37:32 +0100 Received: from relay2.redhat.com by dutecai.et.tudelft.nl (8.6.10/1.34JP) id OAA17854; Thu, 21 Nov 1996 14:53:15 +0100 Received: (qmail 28166 invoked from network); 21 Nov 1996 13:51:04 -0000 Received: from redhat.com (list@199.183.24.1) by relay2.redhat.com with SMTP; 21 Nov 1996 13:51:03 -0000 Received: (from list@localhost) by redhat.com (8.7.4/8.7.3) id IAA10290; Thu, 21 Nov 1996 08:51:17 -0500 X-Envelope-From: dupuis@lei.ucl.ac.be Thu Nov 21 08:51:16 1996 Received: from pc-dupuis.lei.ucl.ac.be (pc-dupuis.lei.ucl.ac.be [130.104.149.210]) by redhat.com (8.7.4/8.7.3) with ESMTP id IAA10280 for <linux-security@redhat.com>; Thu, 21 Nov 1996 08:51:15 -0500 Received: from localhost (dupuis@localhost [127.0.0.1]) by pc-dupuis.lei.ucl.ac.be (8.8.3/8.8.0) with SMTP id OAA02780 for <linux-security@redhat.com>; Thu, 21 Nov 1996 14:53:06 +0100 Date: Thu, 21 Nov 1996 14:53:05 +0100 (MET) From: "Pascal A. Dupuis" <dupuis@lei.ucl.ac.be> Approved: R.E.Wolff@BitWizard.nl Reply-To: "Pascal A. Dupuis" <dupuis@lei.ucl.ac.be> To: linux-security@redhat.com Subject: Having /var/lock as ramdisk : how secure In-Reply-To: <199611210849.JAA00445@cave.et.tudelft.nl> Message-ID: <Pine.LNX.3.95.961121144427.2760A-100000@pc-dupuis.lei.ucl.ac.be> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On a linux box working as PPP server / router / firewall, I wish to spindown the HD for long period of inactivity. But some programs (mgetty) needs to periodically create lock files (in order to test modems). I''ve set up thinks like this : -created a /var/lock.skel dir, containing the directory structure of /var/lock (emacs seems to need its own subdir) -at startup, create a ramdisk on mount it on /var/lock : #create a small ramdisk, mount /var/lock there dd if=/dev/zero of=/dev/ram15 bs=1k count=64 > /dev/null mke2fs -m0 /dev/ram15 64 > /dev/null mount /dev/ram15 /var/lock > /dev/null cp -raf /var/lock.skel/* /var/lock/ >/dev/null This way, creating a log file will not spinup the HD. Added benefit is that there won''t be stale locks after power failure... How safe is it to have things set up this way ? Does it create some security problems ? Thanks in advance Pascal A. Dupuis -- Q: How many existentialists does it take to screw in a lightbulb? A: Two. One to screw it in and one to observe how the lightbulb itself symbolizes a single incandescent beacon of subjective reality in a netherworld of endless absurdity reaching out toward a maudlin cosmos of nothingness. From mail@mail.redhat.com mail2.redhat.com [199.183.24.247]) (mail2.redhat.com rosie.et.tudelft.nl by Received: (qmail 15333 invoked from network); 25 Nov 1996 08:49:13 -0000 Received: from rosie.et.tudelft.nl (130.161.127.248) by mail2.redhat.com with SMTP; 25 Nov 1996 08:48:51 -0000 Received: from cave.et.tudelft.nl (cave.et.tudelft.nl [130.161.127.241]) by rosie.et.tudelft.nl (8.7.4/8.7.3) with ESMTP id JAA26131 for <linux-security@redhat.com>; Mon, 25 Nov 1996 09:42:42 +0100 Received: (from wolff@localhost) by cave.et.tudelft.nl (8.7.6/8.7.3) id JAA00375; Mon, 25 Nov 1996 09:46:15 +0100 Received: from mail2.redhat.com (mail2.redhat.com [199.183.24.247]) by rosie.et.tudelft.nl (8.7.4/8.7.3) with SMTP id PAA23606 for <rogier@cave.et.tudelft.nl>; Sun, 24 Nov 1996 15:36:17 +0100 Received: (qmail 28685 invoked by uid 501); 24 Nov 1996 14:33:08 -0000 Received: (qmail 28551 invoked from network); 24 Nov 1996 14:32:41 -0000 Received: from rosie.et.tudelft.nl (130.161.127.248) by mail2.redhat.com with SMTP; 24 Nov 1996 14:32:25 -0000 Received: from cave.et.tudelft.nl (cave.et.tudelft.nl [130.161.127.241]) by rosie.et.tudelft.nl (8.7.4/8.7.3) with ESMTP id LAA22868 for <linux-security@redhat.com>; Sun, 24 Nov 1996 11:32:28 +0100 Received: (from wolff@localhost) by cave.et.tudelft.nl (8.7.6/8.7.3) id LAA00409 for linux-security@redhat.com; Sun, 24 Nov 1996 11:35:28 +0100 Message-Id: <199611241035.LAA00409@cave.et.tudelft.nl> Subject: Apology. PGP sig mangling. To: linux-security@redhat.com Date: Sun, 24 Nov 1996 11:35:28 +0100 (MET) From: R.E.Wolff@BitWizard.nl (Rogier Wolff) Approved: R.E.Wolff@BitWizard.nl Content-Type: text Hi, I have to apologise: I edited a moderator comment into a message that was pgp-signed. I must say that I normally notice the PGP signature and put comments on those messages in the end, but I must have missed it this time. I''m sorry for the confusion that this must''ve caused. Roger. From mail@mail.redhat.com 8635 by invoked 501); uid Received: (qmail 19567 invoked from network); 26 Nov 1996 00:01:47 -0000 Received: from bach.cis.temple.edu (155.247.71.92) by mail2.redhat.com with SMTP; 26 Nov 1996 00:01:46 -0000 Received: (from alex@localhost) by bach.cis.temple.edu (8.7.4/8.7.3) id TAA12012; Mon, 25 Nov 1996 19:15:01 -0500 Received: from mail2.redhat.com (mail2.redhat.com [199.183.24.247]) by bach.cis.temple.edu (8.7.4/8.7.3) with SMTP id SAA11841 for <alex@bach.cis.temple.edu>; Mon, 25 Nov 1996 18:44:58 -0500 Received: (qmail 8635 invoked by uid 501); 25 Nov 1996 22:51:27 -0000 Received: (qmail 8291 invoked from network); 25 Nov 1996 22:50:58 -0000 Received: from bach.cis.temple.edu (155.247.71.92) by mail2.redhat.com with SMTP; 25 Nov 1996 22:50:57 -0000 Received: from bach.cis.temple.edu (localhost [127.0.0.1]) by bach.cis.temple.edu (8.7.4/8.7.3) with ESMTP id SAA11539; Mon, 25 Nov 1996 18:04:08 -0500 Message-Id: <199611252304.SAA11539@bach.cis.temple.edu> To: linux-alert@redhat.com cc: linux-security@redhat.com Subject: LSF Update#14 v1.2 "lpr vulnerability" Date: Mon, 25 Nov 1996 18:04:01 -0500 From: "Alexander O. Yuriev" <alex@bach.cis.temple.edu> Approved: alex@bach.cis.temple.edu -----BEGIN PGP SIGNED MESSAGE----- $Id: lpr-vulnerability-0.6-linux,v 1.2 1996/11/25 22:39:20 alex Exp $ Linux Security FAQ Update lpr Vulnerability Mon Nov 25 16:56:59 EST 1996 Copyright (C) 1995,1996 Alexander O. Yuriev (alex@bach.cis.temple.edu) CIS Laboratories TEMPLE UNIVERSITY U.S.A. ============================================================================ This is an official Update of the Linux Security FAQ, and it is supposed to be signed by one of the following PGP keys: 1024/ADF3EE95 1995/06/08 Linux Security FAQ Primary Key <Alexander O. Yuriev> Unless you are able to verify at least one of signatures, please be very careful when following instructions. Linux Security WWW: http://bach.cis.temple.edu/linux/linux-security linux-security & linux-alert mailing list archives: ftp://linux.nrao.edu/pub/linux/security/list-archive ============================================================================ REVISION HISTORY (This section in automatically maintained by the Revision Control System ) $Log: lpr-vulnerability-0.6-linux,v $ Revision 1.2 1996/11/25 22:39:20 alex GNU/Debian Linux 1.1 -- Information about the vulnerability corrected A section on lpr version numbering added LPRng release site is used as a distribution site for the LPRng Revision 1.1 1996/11/22 21:42:46 alex Initial revision ABSTRACT A vulnerability exists in the lpr program of Berkeley-derived lpr print-spool program. If installed suid to root, the lpr program allows local users to gain access to a super-user account. This is version 1.2 of the LSF Updated titled "lpr vulnerability" This LSF Update superceeds and obsoletes the LSF Update version 1.1 titled "lpr vulnerability" dated Thu Nov 21 22:24:12 EST 1996. This LSF Update corrects information for Debian/GNU Linux distribution. Due to miscommunication with Debain Project version 1.1 of LSF Update "lpr vulnerability" contained incorrect information regarding vulnerability of Debian/GNU Linux distribution 1.1. This LSF Update also provides explanation of a confusion caused by different version numbering schemes adopted by different distributions. There are no other significant changes in version 1.2 of the LSF Update "lpr vulnerability" compared to version 1.1 of this LSF Update. ABOUT LPR VERSION NUMBERING SCHEMES Unfortunately, different distributions use different version numbering schemes for the same utilities. At this moment, a lpr utility exists in at least the following packages: Berkeley-derived lpr 5.9 lpr.c identifies itself between 1.1 and 1.4 This lpr is vulnerable. Berkeley-derived lpr 5.9, a part of a NetKit 0.6B (separate package) Utilities/System%package lpr name: NetKit-B version: 0.06 Description: Printing support (lpr, lpd, etc) Depending on the release, this version of lpr can be vulnerable. Berkeley-derived lpr 5.9, based on a part of NetKit 0.6B Depending on the release, can be vulnerable. Release lpr-0.12-1 from RedHat is not vulnerable to the lpr bug. LPRng 2.3.12 lpr Part of LPRng print subsystem. lpr.c identifies itself as v3.3 Non-vulnerable to lpr bug. This LSF Update applies to Berkeley-derived lpr 5.9. RISK ASSESSMENT Local users can gain root privileges. The exploits that exercise this vulnerability were made available. VULNERABILITY ANALYSIS lpr utility from Berkeley-derived lpr subsystem, which originally was used in NetKit 0.6B suffers from the buffer overrun problem. Installing lpr as a suid-to-root is needed to allow print spooling. DISTRIBUTION FIXES Red Hat Commercial Linux RedHat 2.1, RedHat 3.0.3 (Picasso) and RedHat 4.0 contain vulnerable lpr utility. Users of RedHat Linux distributions prior to version 4.0 are urged to upgrade to RedHat Linux 4.0 The replacement RPMS are available from the following URLs: RedHat 4.0 x86 Architecture ftp://ftp.redhat.com/pub/redhat/redhat-4.0/updates/i386/lpr-0.12-1.i386.rpm ftp://bach.cis.temple.edu/pub/Linux/Security/DISTRIBUTION-FIXES/RedHat/lpr-0.12-1.i386.rpm RedHat 4.0 Alpha Architecture ftp://ftp.redhat.com/pub/redhat/redhat-4.0/updates/axp/lpr-0.12-1.axp.rpm ftp://bach.cis.temple.edu/pub/Linux/Security/DISTRIBUTION-FIXES/RedHat/lpr-0.12-1.axp.rpm RedHat 4.0 SPARC Architecture ftp://ftp.redhat.com/pub/redhat/redhat-4.0/updates/sparc/lpr-0.12-1.sparc.rpm ftp://bach.cis.temple.edu/pub/Linux/Security/DISTRIBUTION-FIXES/RedHat/lpr-0.12-1.sparc.rpm Please verify the MD5 fingerprint of the RPMs prior to installing them. 6d36461d6c8b6c50ccadf9de530a6136 lpr-0.12-1.i386.rpm 87eb9c5b4d7e6a4217fdb9d3bbd6527b lpr-0.12-1.axp.rpm c04359e61cd16108ce5793aa388f206f lpr-0.12-1.sparc.rpm Caldera Network Desktop Caldera Network Desktop version 1.0 contains a vulnerable lpr program. The replacement RPMS are available from the following URLs: ftp://ftp.caldera.com/pub/cnd-1.0/updates/NetKit-B-lpr-0.06-4c2.i386.rpm ftp://bach.cis.temple.edu/pub/Linux/Security/DISTRIBUTION-FIXES/CND/NetKit-B-lpr-0.06-4c2.i386.rpm WARNING: We are unable to provide the MD5 fingerprint for the replacement kit from Caldea as it was not provided to us. Debian/GNU Linux Debian/GNU Linux 1.1 contains a vulnerable Berkeley-derived lpr utility which is installed as a part of a standard installation. If LPRng package is installed, the Debian/GNU Linux 1.1 contains a non-vulnerable lpr utility. The corrected Debain/GNU Linux 1.1 Berkeley-derived lpr package is available from the following URLs: Debian 1.1 i386 Architecture: ftp://ftp.debian.org/debian/rex/binary-i386/net/lpr_5.9-13.deb ftp://bach.cis.temple.edu/pub/Linux/Security/DISTRIBUTION-FIXES/Debian/lpr_5.9-13.deb Debian-development (no official release) m68k Architecture Debian-development (no official release) sparc Architecture Debian-development (no official release) alpha Architecture There are no binary packages of Berkeley-derived lpr subsystem for these architectures available at this moment. The source package files for lpr are available from the following URLs: ftp://ftp.debian.org/debian/rex/source/net/lpr_5.9-13.tar.gz ftp://ftp.debian.org/debian/rex/source/net/lpr_5.9-13.diff.gz ftp://bach.cis.temple.edu/pub/Linux/Security/DISTRIBUTION-FIXES/Debian/lpr_5.9-13.tar.gz ftp://bach.cis.temple.edu/pub/Linux/Security/DISTRIBUTION-FIXES/Debian/lpr_5.9-13.diff.gz Please verify the MD5 fingerprint of the Debian packages prior to installing them. 4288f4a14b58f439bd0930d2d4631301 lpr_5.9-13.deb ac2f7f38fb410267742c3612ff9d2565 lpr_5.9-13.diff.gz e02b657d2dee61e0efa48b8fb0246b1e lpr_5.9-13.tar.gz In addition to a Berkeley-derived lpr an alternative printing subsystem called LPRng is available for Debian. LPRng is an enhanced printer spooler system, with functionality similar to the Berkeley lpr software. Besides having more features LPRng avoids typical security holes by not running as root. The vulnerability described above doesn''t apply to LPRng. The Debian packages of LPRng are available from the following URLs: Debian 1.1 i386 Architecture ftp://ftp.debian.org/debian/bo/binary-i386/net/lprng_2.4.2-1.deb ftp://bach.cis.temple.edu/pub/Linux/Security/DISTRIBUTION-FIXES/Debian/lprng_2.4.2-1.deb Debian-development (no official release) m68k Architecture Debian-development (no official release) sparc Architecture Debian-development (no official release) alpha Architecture There are no binary packages of LPRng for these architectures available yet. You have to compile them from the sources. The source package files for LPRng are available from the following URLs: ftp://ftp.debian.org/debian/bo/source/net/lprng_2.4.2-1.dsc ftp://ftp.debian.org/debian/bo/source/net/lprng_2.4.2.orig.tar.gz ftp://ftp.debian.org/debian/bo/source/net/lprng_2.4.2-1.diff.gz ftp://bach.cis.temple.edu/pub/Linux/Security/DISTRIBUTION-FIXES/Debian/lprng_2.4.2-1.dsc ftp://bach.cis.temple.edu/pub/Linux/Security/DISTRIBUTION-FIXES/Debian/lprng_2.4.2.orig.tar.gz ftp://bach.cis.temple.edu/pub/Linux/Security/DISTRIBUTION-FIXES/Debian/lprng_2.4.2-1.diff.gz Please verify the MD5 fingerprint of the Debian packages prior to installing them. b791d997d66b67bc1393ffd8281030bc lprng_2.4.2-1.diff.gz c0b60491659d7e074afa58c6329117ad lprng_2.4.2-1.dsc 14b21cd6947e03c517fa50f5ddbb7ef7 lprng_2.4.2.orig.tar.gz Slackware There is no official information available about vulnerability of Slackware 3.0 or Slackware 3.1 distributions from distribution maintainer. The testing indicates that both Slackware 3.0 and Slackware 3.1 distributions contains vulnerable lpr program. Until the official fix-kit for Slackware 3.0 and Slackware 3.1 available system administrators are advised to follow the instructions in the Other Linux Distributions section of this LSF Update. Yggdrasil Yggdrasil Computing Inc neither confirmed not denied vulnerability of Plug and Play Fall''95 Linux. The testing indicates that Plug and Play Fall''95 Linux distribution contains a vulnerable lpr. Until the official fix-kit for Yggdrasil Plug and Play Linux becomes available, system administrators are advised to follow the instructions in the Other Linux Distributions section of this LSF Update Other Linux Distributions It is believed at this moment that all Linux distributions using Berkeley-derived lpr subsystem based on the NetKit 0.06 or prior contain a vulnerable lpr program. Administrators of systems based on distributions not listed in this update or distributions that do not have fix-kits available at the moment are urged to contact their support centers requesting the fix-kits to be made available to them. In order to prevent the vulnerability from being exploited in the mean time, it is recommended that the suid bit is removed from the lpr program using command chmod u-s /usr/bin/lpr Until the official fix-kits are available for those systems, it is advised that system administrators obtain the source code of a LPRng print system used in Debian/GNU Linux 1.1, compile it and replace the Berkeley lpr subsystem. The LPRng software can be obtained from the following URLs: ftp://dickory.sdsu.edu/pub/LPRng/LPRng-2.4.2.tgz ftp://bach.cis.temple.edu/pub/Linux/Security/DISTRIBUTION-FIXES/OTHER/LPRng-2.4.2.tgz Please verify the MD5 fingerprint of the files prior to installing them. 7e96acf72e504189db0dc5ea6982f6f0 LPRng-2.4.2.tgz CREDITS This LSF Update is based on the information originally posted to linux-security mailing list. The information on the fix-kit for Red Hat commercial Linux was provided by Marc Ewing (marc@redhat.com) of Red Hat Software Inc,; for the Caldera Network Desktop by Ron Holt of Caldera Inc.; for Debian/GNU Linux 1.1 by Sven Rudolph <sr1@inf.tu-dresden.de> of Debian Project. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMpog7IxFUz2t8+6VAQFPnAP/SD0K9sfu6jFc6QlH2odDRyaRrDXNWApT 3hoi7Yjjovgd9XNIEhT52l6brZhghrYTv3UHDv6toJxsB3+fCN22SSpxDljdu4v9 EOdS186FK5FigFP3ehU/XFyPta5jNABG9cwNnXmFMuZOPEUwULujS18xEG68hUnn fHKgPLsPpVU=RbMG -----END PGP SIGNATURE----- From mail@mail.redhat.com dutecai.et.tudelft.nl [130.161.38.38]) (dutecai.et.tudelft.nl rosie.et.tudelft.nl by Received: (qmail 16782 invoked from network); 26 Nov 1996 08:33:27 -0000 Received: from rosie.et.tudelft.nl (130.161.127.248) by mail2.redhat.com with SMTP; 26 Nov 1996 08:33:25 -0000 Received: from cave.et.tudelft.nl (cave.et.tudelft.nl [130.161.127.241]) by rosie.et.tudelft.nl (8.7.4/8.7.3) with ESMTP id JAA30517; Tue, 26 Nov 1996 09:13:55 +0100 Received: (from wolff@localhost) by cave.et.tudelft.nl (8.7.6/8.7.3) id JAA00362; Tue, 26 Nov 1996 09:18:01 +0100 Received: from dutecai.et.tudelft.nl (dutecai.et.tudelft.nl [130.161.38.38]) by rosie.et.tudelft.nl (8.7.4/8.7.3) with SMTP id HAA30315 for <rogier@cave.et.tudelft.nl>; Tue, 26 Nov 1996 07:56:42 +0100 Received: from mail2.redhat.com by dutecai.et.tudelft.nl (8.6.10/1.34JP) id UAA10319; Mon, 25 Nov 1996 20:32:53 +0100 Received: (qmail 3035 invoked by uid 501); 25 Nov 1996 18:43:35 -0000 Received: (qmail 2777 invoked from network); 25 Nov 1996 18:43:23 -0000 Received: from phoenix.iss.net (204.241.60.5) by mail2.redhat.com with SMTP; 25 Nov 1996 18:43:23 -0000 Received: from localhost (davem@localhost) by phoenix.iss.net (8.8.3/8.6.12) with SMTP id NAA30955; Mon, 25 Nov 1996 13:41:50 -0500 Date: Mon, 25 Nov 1996 13:41:50 -0500 (EST) From: "David J. Meltzer" <davem@iss.net> Approved: R.E.Wolff@BitWizard.nl To: linux-security@redhat.com, bugtraq@netspace.org Subject: Security Problems in XMCD Message-ID: <Pine.LNX.3.95.961125133751.28145F-100000@phoenix.iss.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII There are security holes in XMCD 2.0pl2 (and presumably all previous versions), a popular audio cd player for numerous unix platforms, which allow a user defined environment variable to overflow a fixed size buffer resulting in a complete compromise of system security on machines with XMCD installed suid root. The cddb_init() function reads in the environment variable XMCD_CDDBPATH, and parses out path names from it, dynamically allocating memory for each pathname as it is parsed. The cd_init() functions, which calls cddb_init(), then uses the structure with the dynamically allocated path string and copies it into a fixed length buffer with: sprintf(str, " %s", pathp->path); The str variable is defined in cd_init() as char str[FILE_PATH_SZ + 2]. Rob McMillan and Georgia Killcrece at CERT, and Ti Kan, the maintainer of XMCD, were made aware of this problem on November 19th. Any questions to CERT regarding this security hole should reference INFO#96.25542. Ti Kan says he has already fixed this problem in a new unreleased version of XMCD, although he was not aware until I explained it in detail that the problem could possibly exist. This new release, or a patch correcting this security problem, has not been made available to the public by Mr. Kan. Questions regarding XMCD should be sent to the maintainer at xmcd@amb.org. Questions regarding CERT''s emergency response or lack thereof to this security hole should be sent to cert@cert.org. Questions regarding security can be sent to me at davem@iss.net. Program: xmcd 2.0pl2 (and previous versions) Affected Operating Systems: All with xmcd installed suid root Requirements: account on system Patch: chmod -s xmcd Security Compromise: root Reported By: David J. Meltzer (davem@iss.net) Synopsis: A buffer overflow in the XMCD_CDDBPATH environment variable allows a user to overwrite the contents of the stack and execute arbitrary code as root. [trad:davem] ~ >./bo --exists -e XMCD_CDDBPATH /usr/X11/bin/xmcd +++ Buffer Overflow Found in XMCD_CDDBPATH environment for /usr/X11/bin/xmcd. [trad:davem] ~ > To test if you are vulnerable to this hole, examine your system for xmcd suid root, and if it exists, fill the XMCD_CDDBPATH environment variable with a large number of characters (ie ''A''). Execute xmcd, if it results in a segmentation fault after a few seconds, you are likely vulnerable to this attack, and should remove the suid bit from xmcd. Exploits for this hole are left as an exercise to the reader. I am not providing a patch for xmcd that fixes this problem because I would not advocate running xmcd, or any other cd player, as suid root on a system regardless of if this or other known security vulnerabilities have been corrected. The probability of more security problems existing outweighs the benefit of being able to listen to music on the console for many situations, make an informed decision when running any program on your machine as root. --------------------------------+--------------------- David J. Meltzer | Email: davem@iss.net Systems Engineer | Web: www.iss.net Internet Security Systems, Inc. | Fax: (770)395-1972 From mail@mail.redhat.com mail2.redhat.com dutecai.et.tudelft.nl by (8.6.10/1.34JP) Received: (qmail 28737 invoked from network); 26 Nov 1996 22:33:38 -0000 Received: from rosie.et.tudelft.nl (130.161.127.248) by mail2.redhat.com with SMTP; 26 Nov 1996 22:33:36 -0000 Received: from cave.et.tudelft.nl (cave.et.tudelft.nl [130.161.127.241]) by rosie.et.tudelft.nl (8.7.4/8.7.3) with ESMTP id WAA00090; Tue, 26 Nov 1996 22:35:21 +0100 Received: (from wolff@localhost) by cave.et.tudelft.nl (8.7.6/8.7.3) id WAA04727; Tue, 26 Nov 1996 22:39:46 +0100 Received: from mail2.redhat.com by dutecai.et.tudelft.nl (8.6.10/1.34JP) id PAA23781; Tue, 26 Nov 1996 15:50:29 +0100 Received: (qmail 15590 invoked by uid 501); 26 Nov 1996 14:31:36 -0000 Received: (qmail 15340 invoked from network); 26 Nov 1996 14:31:00 -0000 Received: from sgiblab.sgi.com (192.82.208.3) by mail2.redhat.com with SMTP; 26 Nov 1996 14:31:00 -0000 Received: from bazooka.amb.org by sgiblab.sgi.com via UUCP (940816.SGI.8.6.9/911001.SGI) id GAA20771; Tue, 26 Nov 1996 06:29:57 -0800 Received: by bazooka.amb.org (Sendmail 5.65/AMB-1.4) id AA19448; Mon, 25 Nov 96 23:08:32 -0800 From: xmcd@bazooka.amb.org (Xmcd Admin) Approved: R.E.Wolff@BitWizard.nl Message-Id: <9611260708.AA19448@bazooka.amb.org> Subject: XMCD v2.1 released (was: Security Problems in XMCD) To: davem@iss.net (David J. Meltzer) Date: Mon, 25 Nov 1996 23:08:30 -0800 (PST) Cc: bugtraq@netspace.org, best-of-security@suburbia.net, linux-security@redhat.com, cert@cert.org, xmcd@bazooka.amb.org In-Reply-To: <Pine.LNX.3.95.961125122334.28145C-100000@phoenix.iss.net> from "David J. Meltzer" at Nov 25, 96 12:45:32 pm X-Mailer: ELM [version 2.4 PL22] Content-Type: text This is to announce that XMCD 2.1 patchlevel 0 has been released which fixes all of the issues previously raised by David Meltzer. It also contains a number of other minor feature and functionality enhancements. The new version may be obtained via the xmcd web page at: http://sunsite.unc.edu/~cddb/xmcd/ Users of xmcd with older versions are encouraged to upgrade. -Ti -- \\ // XMCD - Motif CD player / CDA - Command line CD player \\/ Ti Kan / AMB Research Laboratories //\ E-mail: xmcd@amb.org // \\ URL: http://sunsite.unc.edu/~cddb/xmcd/ David J. Meltzer <davem@iss.net> wrote:> There are security holes in XMCD 2.0pl2 (and presumably all previous > versions), a popular audio cd player for numerous unix platforms, which > allow a user defined environment variable to overflow a fixed size buffer > resulting in a complete compromise of system security on machines with XMCD > installed suid root. > [ ... description deleted ]From mail@mail.redhat.com dutecai.et.tudelft.nl [130.161.38.38]) (dutecai.et.tudelft.nl rosie.et.tudelft.nl by Received: (qmail 28876 invoked from network); 26 Nov 1996 22:34:01 -0000 Received: from rosie.et.tudelft.nl (130.161.127.248) by mail2.redhat.com with SMTP; 26 Nov 1996 22:33:55 -0000 Received: from cave.et.tudelft.nl (cave.et.tudelft.nl [130.161.127.241]) by rosie.et.tudelft.nl (8.7.4/8.7.3) with ESMTP id WAA00226; Tue, 26 Nov 1996 22:45:36 +0100 Received: (from wolff@localhost) by cave.et.tudelft.nl (8.7.6/8.7.3) id WAA04872; Tue, 26 Nov 1996 22:50:03 +0100 Received: from dutecai.et.tudelft.nl (dutecai.et.tudelft.nl [130.161.38.38]) by rosie.et.tudelft.nl (8.7.4/8.7.3) with SMTP id WAA00109 for <rogier@cave.et.tudelft.nl>; Tue, 26 Nov 1996 22:35:42 +0100 Received: from mail2.redhat.com by dutecai.et.tudelft.nl (8.6.10/1.34JP) id TAA14050; Tue, 26 Nov 1996 19:49:19 +0100 Received: (qmail 19784 invoked by uid 501); 26 Nov 1996 18:23:06 -0000 Received: (qmail 19732 invoked from network); 26 Nov 1996 18:23:00 -0000 Received: from phoenix.iss.net (204.241.60.5) by mail2.redhat.com with SMTP; 26 Nov 1996 18:22:58 -0000 Received: from localhost (davem@localhost) by phoenix.iss.net (8.8.3/8.6.12) with SMTP id NAA14401; Tue, 26 Nov 1996 13:06:17 -0500 Date: Tue, 26 Nov 1996 13:06:15 -0500 (EST) From: "David J. Meltzer" <davem@iss.net> Approved: R.E.Wolff@BitWizard.nl To: Xmcd Admin <xmcd@bazooka.amb.org> cc: bugtraq@netspace.org, best-of-security@suburbia.net, linux-security@redhat.com, cert@cert.org Subject: Security Problems in XMCD 2.1 In-Reply-To: <9611260708.AA19448@bazooka.amb.org> Message-ID: <Pine.LNX.3.95.961126122846.12271F-100000@phoenix.iss.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII> This is to announce that XMCD 2.1 patchlevel 0 has been released > which fixes all of the issues previously raised by David Meltzer. > It also contains a number of other minor feature and functionality > enhancements.I have obtained the 2.1 release of XMCD and through a cursory examination of the code have uncovered another buffer overflow problem that appear to be exploitable to gain root access on the system. I have not verified that the hole is exploitable, although it definitely exists. As I stated before, if you remove the suid bit from xmcd, then you do not have to worry about upgrading other than for the new features that have been added, whether you can still function xmcd without the suid bit varies depending on your system. I have a limited amount of time I can spend in examining source code, and I apologize I am unable to find every potential hole in programs I examine. I can provide no assurance that there are not additional security holes in xmcd due to the limited nature of my examination of the code; to provide some level of assurance would take a far more detailed examination that I simply can not devote the time to achieve for a non-critical piece of code such as xmcd. The offending line of code is in cdfunc.c in the cd_init() function: sprintf(titlestr, "%s %d", app_data.main_title, app_data.devnum); The titlestr is defined to be char titlestr[STR_BUF_SZ]. The string app_data.main_title is read from the XMcd resource file which will be read from a user''s home directory. A user can then modify the XMcd*mainWindowTitle resource to an arbitrary length string. Questions regarding XMCD should be sent to the maintainer at xmcd@amb.org. Questions to CERT regarding this problem should be sent to cert@cert.org referencing INFO#96.25542. Program: xmcd 2.1 (and previous versions) Affected Operating Systems: All with xmcd installed suid root Requirements: account on system Patch: chmod -s xmcd Security Compromise: root Reported By: David J. Meltzer (davem@iss.net) Synopsis: A buffer overflow in the XMcd*mainWindowTitle resource allows a user to overwrite the contents of the stack and execute arbitrary code as root. <Tue | 12:53> [sn0p:davem] ~ >which xmcd /usr/X11/bin/xmcd <Tue | 12:53> [sn0p:davem] ~ >ls -l /usr/X11/bin/xmcd -rws--x--x 1 root bin 1048484 Nov 26 12:21 /usr/X11/bin/xmcd <Tue | 12:53> [sn0p:davem] ~ >echo ''XMcd*mainWindowTitle: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA'' > XMcd <Tue | 12:54> [sn0p:davem] ~ >xmcd Segmentation fault <Tue | 12:54> [sn0p:davem] ~ > --------------------------------+--------------------- David J. Meltzer | Email: davem@iss.net Systems Engineer | Web: www.iss.net Internet Security Systems, Inc. | Fax: (770)395-1972 From mail@mail.redhat.com Thu Nov 14 09:15:34 1996
[Mod: Subject changed and a part about modules removed. Also, if people have comments, please email them directly to Jim and me - we will post a summary. -- alex]>>> To be honest, I haven''t gone through the trouble >>> of coding a module yet, but compiled kernels with securelevel=1 works. :) >>> It''s a nice lock+key function when you''re looking to immute or append- >>> only special files. (Immuting /etc/passwd on production machines is a >>> simple security measure that saves hours of time... trust me.) >> >> Which will prevent passwd, chfn and chsh work.... So no, I won''t >> trust you.So. I believe he was referring to dedicated servers, like ftp, web, nfs, db servers, and the like. These boxes -- to be considered reasonably secure -- should have not user level accounts on them -- just administrative accounts. I agree that there are many types of "production" machines where you don''t want /etc/passwd and /etc/aliases, and /etc/sendmail.cf (etc). to be immutable. However I do recommend setting all libs, bins, kernels, man pages (groff macro trojans), and as many other files to immutable as you can. Do this *even if you don''t set sysctl*. [Mod: Even on dedicated systems one needs to change passwords. The question becomes more of a policy issue. Using a principle of the least priviledge, one would expect that becoming superuser in order to just change a password of one of the www admins is a not a good idea. Also keep in mind that package manegers do not check for the immutable flags which prevent easy package upgrades. -- alex]>>> I did, >>> however, notice a couple of broken things in the immutable area, namely, >>> the execption for root is tested before the immutable kick-out code. >>> The main reason I use the immute/append tags are so processes running >>> as root CANT alter certain files. (Ie a human has to un-tag the files >>> before they can be altered).I don''t know about the code -- but I''ve chattr''d +i and was unable to modify files as root. So it has worked as *I* expected. [Mod: from chattr(1) manual page: A file with the ''a'' attribute set can only be open in append mode for writing. A file with the ''s'' attribute cannot be modified: it can- not be deleted or renamed, no link can be created to this file and no data can be written to the file. Only the superuser can set or clear this attribute. -- alex]> > Correct me if I am wrong but is not chattr a wrapper against a system call? > > Who will prevent a program running as root to issue such call? Essentially, > > I think we can agree that there is no way to prevent a smart attacker from > > penetrating a system, you can only make your system harder to penetrate than > > a system of your neighbour.I suspect that you''re wrong -- but I haven''t looked at the code. Clearly an immutable file can be unprotected by ''chattr -i'' by a root process -- until we have securelevel working.> The securelevel code simply isn''t finished. I suspect Remi Card had the > feeling he wanted a securelevel variable, stuck it in in his area of the > code (ext2fs) and put in a little code in the sysctl as an example of how > this variable might be changed. > > When securelevel <> 0, you should > 1) Disable writing/reading block devices. (i.e. you can no longer use mtools > for floppies) > 2) disable writing/reading char devices, except maybe mouse and serial > ports. (At least kmem should be disabled, which is a char device.)I disagree with both of these statements. You could be able to access the block and char devices according to their permissions. I also think that you should be able to create new b and c nodes according to the filesystem permissions. However I think that filesystems should not be mountable or remountable after securelevel is set. At least there should be some mechanism by which mounting, remounting and unmounting is only supported according to the settings in /etc/fstab -- no override via command line parms. (Otherwise you can mount removable backup devices).> 3) Disable module loading. > 4) disable the chattr call for ext2fs.I agree with this -- securelevel should prevent changes to the kernel memory space that would render the system insecure.> Only (4) is implemented right now.Jim Dennis, Starshine Technical Services