From owner-freebsd-security Sun Mar 14 0:27: 9 1999 Delivered-To: freebsd-security@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id AA67B150AC for ; Sun, 14 Mar 1999 00:27:05 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id AAA89058; Sun, 14 Mar 1999 00:26:45 -0800 (PST) (envelope-from dillon) Date: Sun, 14 Mar 1999 00:26:45 -0800 (PST) From: Matthew Dillon Message-Id: <199903140826.AAA89058@apollo.backplane.com> To: David Scheidt Cc: The Unicorn , freebsd-security@FreeBSD.ORG Subject: Re: ACLs References: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org ::the number of links to the file the inode holds information on. Therefor ::any admin who is worth the money they receive for doing their task will ::know that if the number of links to a file is greater than one another ::hard link must exist. Searching the filesystem for another name ::referring the same inode is then not a really hard thing to do... :: : :You have to remeber to check, though. I don't look at the link count every :time before I a rm a file. There are all sorts of people admining boxes who :haven't sense to check for this. I suspect there are lots of otherwise :competent people who don't even know to look for this. Removing the problem :might be a better solution than trying to educate the world about it. If you have your machine partitioned correctly, you do not generally have to worry about hardlinks to system binaries ( suid or otherwise ) as users do not have access to partitions containing them. If you are really worried about it, simply chmod and truncate the file before removing it. If you are truely paranoid, chmod the file, rewrite the contents with garbarge, fsync, ( repeat 50 times ), *then* truncate and remove the file. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Mar 14 1:44:30 1999 Delivered-To: freebsd-security@freebsd.org Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id 3F09614E0E for ; Sun, 14 Mar 1999 01:44:26 -0800 (PST) (envelope-from peter.jeremy@auss2.alcatel.com.au) Received: by border.alcanet.com.au id <40323>; Sun, 14 Mar 1999 19:31:50 +1000 Date: Sun, 14 Mar 1999 19:43:57 +1000 From: Peter Jeremy Subject: Re: disapointing security architecture To: freebsd-security@FreeBSD.ORG Message-Id: <99Mar14.193150est.40323@border.alcanet.com.au> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Wes Peters wrote: >My suggestion for FreeBSD would be to steal half of the disk direct >blocks in the disk inode for ACL information. The downside of this is that _all_ files between 7 and 12 blocks long (typically 48-96KB) will then need an indirect block - adding an extra block to its size (additional indirect blocks are needed for other sizes as well, but this first one is the biggest relative space/time hit). Whilst this may be reasonable for a system where the majority of the files have individual ACLs, I suspect this wouldn't be true of most systems. IMHO, stealing an extra inode (or disk block) only for files that need ACLs would be preferable (especially if ACL sharing is implemented). Admittedly, we still need to find space for the additional pointer in the inode. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Mar 14 2: 8:17 1999 Delivered-To: freebsd-security@freebsd.org Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id 6E6F61503E for ; Sun, 14 Mar 1999 02:07:57 -0800 (PST) (envelope-from peter.jeremy@auss2.alcatel.com.au) Received: by border.alcanet.com.au id <40346>; Sun, 14 Mar 1999 19:55:21 +1000 Date: Sun, 14 Mar 1999 20:07:28 +1000 From: Peter Jeremy Subject: Re: ACL's To: robert+freebsd@cyrus.watson.org Cc: freebsd-security@FreeBSD.ORG Message-Id: <99Mar14.195521est.40346@border.alcanet.com.au> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Robert Watson wrote: >BTW, I'd really like to get rid of hard links -- they allow users to >retain copies of setuid files after the owner thinks they are deleted. This strikes me as overkill. Why not just change either rm(1) or unlink(2) to remove set[gu]id bits on executables? This would have the same net effect and the behaviour can probably be justified. >I.e., user creates a hard link to /usr/sbin/somesetuidbin to >/usr/tmp/mytemp. Normal users shouldn't have write permission anywhere on a partition containing system binaries - this also removes the problem. (Note that /usr/tmp is accessible only by root under FreeBSD). Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Mar 14 2:49:48 1999 Delivered-To: freebsd-security@freebsd.org Received: from aniwa.sky (p25-max12.wlg.ihug.co.nz [216.100.145.25]) by hub.freebsd.org (Postfix) with ESMTP id C37B014F3B for ; Sun, 14 Mar 1999 02:48:56 -0800 (PST) (envelope-from andrew@squiz.co.nz) Received: from aniwa.sky (localhost [127.0.0.1]) by aniwa.sky (8.9.1a/8.9.1) with ESMTP id XAA06895; Sun, 14 Mar 1999 23:48:18 +1300 (NZDT) Message-Id: <199903141048.XAA06895@aniwa.sky> X-Mailer: exmh version 2.0.2 2/24/98 To: Peter Jeremy Cc: robert+freebsd@cyrus.watson.org, freebsd-security@FreeBSD.ORG Subject: Re: ACL's In-reply-to: Your message of "Sun, 14 Mar 1999 20:07:28 +1000." <99Mar14.195521est.40346@border.alcanet.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 14 Mar 1999 23:48:17 +1300 From: Andrew McNaughton Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Peter Jeremy wrote: > Robert Watson wrote: > >I.e., user creates a hard link to /usr/sbin/somesetuidbin to > >/usr/tmp/mytemp. > > Normal users shouldn't have write permission anywhere on a partition > containing system binaries - this also removes the problem. (Note > that /usr/tmp is accessible only by root under FreeBSD). There's some sense in that. It's worthy of note then that this is not how a FreeBSD default install is set up. Perhaps it should be? Andrew McNaughton -- ----------- Andrew McNaughton andrew@squiz.co.nz http://www.newsroom.co.nz/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Mar 14 4:17:17 1999 Delivered-To: freebsd-security@freebsd.org Received: from nomad.dataplex.net (nomad.dataplex.net [208.2.87.8]) by hub.freebsd.org (Postfix) with ESMTP id 73A8C14BE3 for ; Sun, 14 Mar 1999 04:16:56 -0800 (PST) (envelope-from rkw@dataplex.net) Received: from localhost (rkw@localhost) by nomad.dataplex.net (8.9.2/8.9.2) with ESMTP id GAA09539; Sun, 14 Mar 1999 06:15:06 -0600 (CST) (envelope-from rkw@dataplex.net) X-Authentication-Warning: nomad.dataplex.net: rkw owned process doing -bs Date: Sun, 14 Mar 1999 06:15:06 -0600 (CST) From: Richard Wackerbarth Reply-To: rkw@dataplex.net To: David Scheidt Cc: The Unicorn , freebsd-security@FreeBSD.ORG Subject: Re: ACLs In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 14 Mar 1999, David Scheidt wrote: > Programs which do different things depending on the name they are invoked > under is not a feature. > > :Just my 0.02 euro. Then you have never looked at "crunched" binaries which combine many programs into one in order to remove redundancy in static binaries and try to fit them in a limited space (read a single floppy) as with PicoBSD. Your euro may be fine in the part of the world where you customarily reside. However, "our" needs in Fiji are different and "we" don't accept euro. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Mar 14 5:50:44 1999 Delivered-To: freebsd-security@freebsd.org Received: from obie.softweyr.com (unknown [204.68.178.33]) by hub.freebsd.org (Postfix) with ESMTP id 0AF6314BFF for ; Sun, 14 Mar 1999 05:50:38 -0800 (PST) (envelope-from wes@softweyr.com) Received: from softweyr.com (wes@zaphod.softweyr.com [204.68.178.35]) by obie.softweyr.com (8.8.8/8.8.8) with ESMTP id GAA09329; Sun, 14 Mar 1999 06:50:12 -0700 (MST) (envelope-from wes@softweyr.com) Message-ID: <36EBBE93.DEC82C92@softweyr.com> Date: Sun, 14 Mar 1999 06:50:11 -0700 From: Wes Peters Organization: Softweyr llc X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Peter Jeremy Cc: freebsd-security@FreeBSD.ORG Subject: Re: disapointing security architecture References: <99Mar14.193150est.40323@border.alcanet.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Peter Jeremy wrote: > > Wes Peters wrote: > >My suggestion for FreeBSD would be to steal half of the disk direct > >blocks in the disk inode for ACL information. > > The downside of this is that _all_ files between 7 and 12 blocks long > (typically 48-96KB) will then need an indirect block - adding an extra > block to its size (additional indirect blocks are needed for other > sizes as well, but this first one is the biggest relative space/time > hit). Whilst this may be reasonable for a system where the majority > of the files have individual ACLs, I suspect this wouldn't be true > of most systems. Actually, only the ones that have ACLs will take this hit, since you don't have to reserve the space if the file type isn't "file with ACL." I see a couple of holes in this theory, though: you need ACLs on device files too, and it becomes very expensive to add an ACL to a file after the fact, since you have to "push down" all the blocks in order to clear the ACL entries. > IMHO, stealing an extra inode (or disk block) only for files that need > ACLs would be preferable (especially if ACL sharing is implemented). I agree, but I'm not sure how you would express the ACL sharing idea to the user. When the user adds an ACL to a file, are you just going to exhaustively search all existing ACLs to see if one matches? What do you do if two files are sharing an ACL and a user edits one? Change both? Split a new ACL? > Admittedly, we still need to find space for the additional pointer > in the inode. The ufs dinode has two "spare" int32_t's at the end, that should do it. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.softweyr.com/~softweyr wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Mar 14 8:59:24 1999 Delivered-To: freebsd-security@freebsd.org Received: from dhabat.pair.com (dhabat.pair.com [209.68.1.219]) by hub.freebsd.org (Postfix) with ESMTP id 6650415129 for ; Sun, 14 Mar 1999 08:59:21 -0800 (PST) (envelope-from alanp@dhabat.pair.com) Received: (from alanp@localhost) by dhabat.pair.com (8.9.1/8.6.12) id LAA29296; Sun, 14 Mar 1999 11:59:01 -0500 (EST) X-Envelope-To: freebsd-security@freebsd.org Message-ID: <19990314115901.A29122@unixpower.org> Date: Sun, 14 Mar 1999 11:59:01 -0500 From: Alan To: Marc Slemko Cc: freebsd-security@freebsd.org Subject: Re: bind 8.1.2 cache poisoning References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1 In-Reply-To: ; from Marc Slemko on Sat, Mar 13, 1999 at 10:53:36PM -0800 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, Mar 13, 1999 at 10:53:36PM -0800, Marc Slemko wrote: > On Sat, 13 Mar 1999, Jesse wrote: > > Yup, it can be done. There are three or four programs that I have seen > which do it. > > The way an name server can match a response to a request is by looking > at the query id. This query id is a 16 bit number. If you can guess > that number, you can often spoof a response. > Really, I have only seen 2. > > Hmm? I'm not sure what you are talking about. The root name servers do > not run with recursion enabled making this attack not work against them. > Hmmph.... I admin a box for a friend, and I saw people who had root 'snoof'ing stuff like 'owned.microsoft.com' onto a.root-servers.net. It's really sad when people you think you can trust do things like that. -- | Alan L. * Webmaster of www.UnixPower.org | | Windsor Unix Users Group Founder: http://unix.windsor.on.ca/ | | Personal Page: http://www.unixpower.org/alanp/ | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Mar 14 9:19:57 1999 Delivered-To: freebsd-security@freebsd.org Received: from fledge.watson.org (FLEDGE.RES.CMU.EDU [128.2.93.229]) by hub.freebsd.org (Postfix) with ESMTP id 09122151D4 for ; Sun, 14 Mar 1999 09:19:42 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id MAA05252; Sun, 14 Mar 1999 12:16:48 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Sun, 14 Mar 1999 12:16:47 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: The Unicorn Cc: Thomas Valentino Crimi , freebsd-security@FreeBSD.ORG Subject: Re: ACL's In-Reply-To: <19990314081933.A438@unicorn.quux.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 14 Mar 1999, The Unicorn wrote: > On Sat, Mar 13, 1999 at 07:26:52PM -0500, Robert Watson wrote: > > On Sat, 13 Mar 1999, Thomas Valentino Crimi wrote: > > > > [ POSIX related stuff deleted... ] > > > BTW, I'd really like to get rid of hard links -- they allow users to > > retain copies of setuid files after the owner thinks they are deleted. > > I.e., user creates a hard link to /usr/sbin/somesetuidbin to > > /usr/tmp/mytemp. Now the admin upgrades the machine, thinking they have > > removed the risk of the now known buggy somesetuidbin. > > > > Also, since directory permissions act as a cumlative masks on the > > permissions of files held in them, it can be hard to revoke access to a > > file you own--someone else may have hard linked it elsewhere in the fs > > without your knowledge (something they can do as long as they own the > > target directory). Given that hard links already cause inconsistent > > semantics in the name space for users, and aren't properly preserved in > > tar, etc, I think they don't contribute much. > > They cause inconsistent semantics, but they are recorded in the inode as > the number of links to the file the inode holds information on. Therefor > any admin who is worth the money they receive for doing their task will > know that if the number of links to a file is greater than one another > hard link must exist. Searching the filesystem for another name > referring the same inode is then not a really hard thing to do... Race conditions? There is guarantee that between your stat() and unlink() no one else can do an link(). Same goes for searching. The same response applies in my mind to the prevent-linking-of-setuid suggestion -- if you do an atomic open() with O_CREAT and O_EXCL, and specify the correct mode at creation, you can indeed manage this correctly. But many utilities become setuid by virtue of the chmod user command, allowing for a race wherein the file is created, linked, and then chmod'd. I concede the point on GNU tar -- it indeed appears to handle hard links on files correctly. However, I still argue that the ability to sometimes ln and sometimes not ln is probably not consistent. Robert N Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: 03 01 DD 8E 15 67 48 73 25 6D 10 FC EC 68 C1 1C Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ Safeport Network Services http://www.safeport.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Mar 14 9:25:12 1999 Delivered-To: freebsd-security@freebsd.org Received: from fledge.watson.org (FLEDGE.RES.CMU.EDU [128.2.93.229]) by hub.freebsd.org (Postfix) with ESMTP id 3521915428 for ; Sun, 14 Mar 1999 09:25:05 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id MAA05307; Sun, 14 Mar 1999 12:24:43 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Sun, 14 Mar 1999 12:24:43 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Peter Jeremy Cc: freebsd-security@FreeBSD.ORG Subject: Re: ACL's In-Reply-To: <99Mar14.195521est.40346@border.alcanet.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 14 Mar 1999, Peter Jeremy wrote: > Robert Watson wrote: > > >I.e., user creates a hard link to /usr/sbin/somesetuidbin to > >/usr/tmp/mytemp. > > Normal users shouldn't have write permission anywhere on a partition > containing system binaries - this also removes the problem. (Note > that /usr/tmp is accessible only by root under FreeBSD). But many common FS arrangements do use the same partition for a world-writable directory and the binaries. For example: /var on /usr/var (/var has /var/tmp) /usr/local/ on /usr (The tex port requires a world-writable temp directory) /tmp on / (/sbin is usually on /; default install I believe) /home on /usr/home (default install I believe) I like the idea of the FS namespace having consistent semantics--counter-intuitive security behavior like "the system is relatively secure as long as you don't partition the system in any way that allows these files to be on the same partition as these files..." seems best to be avoided. I think hard links are neat, et al, but I really don't think they add any new useful functionality above symlinks, and they can certainly introduce new problems. They save a little disk space here and there (as long as you don't recursive move anything)... Robert N Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: 03 01 DD 8E 15 67 48 73 25 6D 10 FC EC 68 C1 1C Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ Safeport Network Services http://www.safeport.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Mar 14 9:35: 6 1999 Delivered-To: freebsd-security@freebsd.org Received: from fledge.watson.org (FLEDGE.RES.CMU.EDU [128.2.93.229]) by hub.freebsd.org (Postfix) with ESMTP id 629F615514 for ; Sun, 14 Mar 1999 09:35:04 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id MAA05349; Sun, 14 Mar 1999 12:33:55 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Sun, 14 Mar 1999 12:33:55 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Richard Wackerbarth Cc: David Scheidt , The Unicorn , freebsd-security@FreeBSD.ORG Subject: Re: ACLs In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 14 Mar 1999, Richard Wackerbarth wrote: > On Sun, 14 Mar 1999, David Scheidt wrote: > > > Programs which do different things depending on the name they are invoked > > under is not a feature. > > > > :Just my 0.02 euro. > > Then you have never looked at "crunched" binaries which combine many > programs into one in order to remove redundancy in static binaries > and try to fit them in a limited space (read a single floppy) as with > PicoBSD. > > Your euro may be fine in the part of the world where you customarily > reside. However, "our" needs in Fiji are different and "we" don't accept > euro. This can be done using symlinks in just the same way. Robert N Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: 03 01 DD 8E 15 67 48 73 25 6D 10 FC EC 68 C1 1C Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ Safeport Network Services http://www.safeport.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Mar 14 9:45: 7 1999 Delivered-To: freebsd-security@freebsd.org Received: from gndrsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id 63A7B14E61 for ; Sun, 14 Mar 1999 09:44:45 -0800 (PST) (envelope-from rgrimes@gndrsh.aac.dev.com) Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.8.8/8.8.8) id JAA22396; Sun, 14 Mar 1999 09:42:30 -0800 (PST) (envelope-from rgrimes) From: "Rodney W. Grimes" Message-Id: <199903141742.JAA22396@gndrsh.aac.dev.com> Subject: Re: ACLs was disapointing security architecture In-Reply-To: <19990313203902.B1850@austin.rr.com> from Alan Weber at "Mar 13, 99 08:39:02 pm" To: aaweber@austin.rr.com (Alan Weber) Date: Sun, 14 Mar 1999 09:42:30 -0800 (PST) Cc: robert+freebsd@cyrus.watson.org, freebsd-security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [Trim old context] > > I am not suggesting directory-only ACLs but want the file ACL to point to the > directory ACL unless explicitly changed on a per file basis. I like the above > scheme to reuse ACLs as one change can be efficiently propagated to a huge number > of files versus having to fetch/update every file ACL in a directory hierarchy. > Apollo/Agies and Apollo Domain/OS implemented it something like this, only I think the ACL's where stored as seperate UUID objects and files/directories had pointers to them. A UUID is kinda like an inode, but a lot more flexable in what it can do. They also had a utility known as salacl (salvage acl's) that would walk a disk volume for all acl's and find ones that had the same values, then collapse all the pointers to a minimum set of acl's. In the early days of Apollo/Agies is you did not run salacl at least once a week performance really started to suck. Latter they improved the ACL cache code and this became less of a problem unless you where doing lots of changes to a volumes ACL's. -- Rod Grimes - KD7CAX - (RWG25) rgrimes@gndrsh.aac.dev.com Accurate Automation, Inc. Reliable computers for FreeBSD http://www.aai.dnsmgr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Mar 14 10:48:23 1999 Delivered-To: freebsd-security@freebsd.org Received: from host07.rwsystems.net (kasie.rwsystems.net [209.197.192.103]) by hub.freebsd.org (Postfix) with ESMTP id C1B31150FC for ; Sun, 14 Mar 1999 10:47:53 -0800 (PST) (envelope-from jwyatt@RWSystems.net) Received: from kasie.rwsystems.net([209.197.192.103]) (4016 bytes) by host07.rwsystems.net via sendmail with P:esmtp/R:bind_hosts/T:inet_zone_bind_smtp (sender: ) id for ; Sun, 14 Mar 1999 12:16:48 -0600 (CST) (Smail-3.2.0.104 1998-Nov-20 #1 built 1998-Dec-24) Date: Sun, 14 Mar 1999 12:16:29 -0600 (CST) From: James Wyatt To: The Unicorn Cc: Robert Watson , Thomas Valentino Crimi , freebsd-security@FreeBSD.ORG Subject: Re: ACL's In-Reply-To: <19990314081933.A438@unicorn.quux.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 14 Mar 1999, The Unicorn wrote: > On Sat, Mar 13, 1999 at 07:26:52PM -0500, Robert Watson wrote: > > BTW, I'd really like to get rid of hard links -- they allow users to > > retain copies of setuid files after the owner thinks they are deleted. > > I.e., user creates a hard link to /usr/sbin/somesetuidbin to > > /usr/tmp/mytemp. Now the admin upgrades the machine, thinking they have > > removed the risk of the now known buggy somesetuidbin. To quote Bill The Cat: Ack! Phht! No! Please, No! I use arg0 in a lot of my programming when it's useful to have common code that does related, but different, things. (Please look at the boot disk, vi/ex/view/nvi/nex/nview, gzip/gunzip/zcat/gzcat, gcc/cc, compress/uncompress, etc...) If you want to find more, just try: find / -links +1 -type f -print | xargs ls -l | more This is just too useful to most folks to save the sysadmin who doesn't read their nightly security mailings. It is also why I like a /tmp filesys (as well as a /home) filesys on machines with real users. Don't let them link on drives w/important binaries and don't let them vi ~/bigfile to fill-up /tmp and hurt everyone using '/'! Ensure, if you have one, that ~ftp/incoming is a separate filesys too. 8{) > > Also, since directory permissions act as a cumlative masks on the > > permissions of files held in them, it can be hard to revoke access to a > > file you own--someone else may have hard linked it elsewhere in the fs > > without your knowledge (something they can do as long as they own the > > target directory). Given that hard links already cause inconsistent > > semantics in the name space for users, and aren't properly preserved in > > tar, etc, I think they don't contribute much. Geez, even SCO Xenix tar got this right. Dump can't miss it and cpio gets it right (even on devs!); so who's tar broke this? (Minix doesn't count 8{) > They cause inconsistent semantics, but they are recorded in the inode as > the number of links to the file the inode holds information on. Therefor > any admin who is worth the money they receive for doing their task will > know that if the number of links to a file is greater than one another > hard link must exist. Searching the filesystem for another name > referring the same inode is then not a really hard thing to do... Uh, I know a lot of admins that I consider 'worth their salt' who don't check link counts (or maybe even notice them in an 'ls -l') before removing a file. I don't think system upgrade scripts do it either. > Have a look at ls -l `which vi view ex` and think again about what hard > links contribute (then again similar functionality might be constructed > using soft-links; but they are much harder to administrate (read: keep > under control)) Symlinks do not prevent the original binary from being unavailable. Please remember that files don't really go away until all links are zero and no more filedescs are open on them. Hey, if 'the founders' had meant for symlinks to be used over hard links, there would have been an 'ls -h' flag, right? 8{) > Just my 0.02 euro. This means it's euro-pinion? What's the conversion rate? - Jy@ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Mar 14 11: 8:13 1999 Delivered-To: freebsd-security@freebsd.org Received: from fledge.watson.org (FLEDGE.RES.CMU.EDU [128.2.93.229]) by hub.freebsd.org (Postfix) with ESMTP id 93F1F153E9 for ; Sun, 14 Mar 1999 11:08:11 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id OAA05643; Sun, 14 Mar 1999 14:07:03 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Sun, 14 Mar 1999 14:07:02 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: James Wyatt Cc: The Unicorn , Thomas Valentino Crimi , freebsd-security@FreeBSD.ORG Subject: Re: ACL's In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 14 Mar 1999, James Wyatt wrote: > On Sun, 14 Mar 1999, The Unicorn wrote: > > On Sat, Mar 13, 1999 at 07:26:52PM -0500, Robert Watson wrote: > > > BTW, I'd really like to get rid of hard links -- they allow users to > > > retain copies of setuid files after the owner thinks they are deleted. > > > I.e., user creates a hard link to /usr/sbin/somesetuidbin to > > > /usr/tmp/mytemp. Now the admin upgrades the machine, thinking they have > > > removed the risk of the now known buggy somesetuidbin. > > To quote Bill The Cat: Ack! Phht! > No! Please, No! I use arg0 in a lot of my programming when it's useful to > have common code that does related, but different, things. (Please look at > the boot disk, vi/ex/view/nvi/nex/nview, gzip/gunzip/zcat/gzcat, gcc/cc, > compress/uncompress, etc...) If you want to find more, just try: > > find / -links +1 -type f -print | xargs ls -l | more symlinks, when executed, pass the symlink name as arg0. > This is just too useful to most folks to save the sysadmin who doesn't > read their nightly security mailings. It is also why I like a /tmp filesys > (as well as a /home) filesys on machines with real users. Don't let them > link on drives w/important binaries and don't let them vi ~/bigfile to > fill-up /tmp and hurt everyone using '/'! Ensure, if you have one, that > ~ftp/incoming is a separate filesys too. 8{) There seems to be some contradiction here: you want users without extensive security experience and unwilling to look at nightly security mailings to know how to partition systems in the manner you describe? What about users who use setuid so that their CGI scripts execute as their own UID? This means having more than one user per partition is a bad idea. The merits of a MFS /tmp (cleared at boot, restricted in size, etc) should not be confused with the merits of secure file system behavior. All I want is for it to be safe for me to have a setuid binary on the same file system as a temporary directory. File systems were not intended to be the partitioning points for security domains -- they are for file storage as binary blobs :-). Don't overload security characteristics onto local hard disk arrangement. I know that this already happens somewhat, but I'd like to try and reduce it in the name of KISS and consistency. Especially given how many people run with so many different partition arrangements. Personally, on notebooks, I like to have everything except tmp on one partition, and have tmp on MFS. This means that the slack space from each partition is not wasted in places where it won't be needed (not much mail delivery on my notebook). On the other hand, it doesn't meet the requirement that each user home directory, world-writable directory (*/tmp, texmf, etc), etc, be on a different partion :-). And it does end up being a multi-user machine (a poor distinction except from the point of view of performance operation in my view) because sometimes I need to access it remotely, or give other people access to files on it. > > > Also, since directory permissions act as a cumlative masks on the > > > permissions of files held in them, it can be hard to revoke access to a > > > file you own--someone else may have hard linked it elsewhere in the fs > > > without your knowledge (something they can do as long as they own the > > > target directory). Given that hard links already cause inconsistent > > > semantics in the name space for users, and aren't properly preserved in > > > tar, etc, I think they don't contribute much. > > Geez, even SCO Xenix tar got this right. Dump can't miss it and cpio gets > it right (even on devs!); so who's tar broke this? (Minix doesn't count 8{) Recursive cp? (The intuitive, simple, *man page recommended* way to copy a directory from one hard disk to another?) > > They cause inconsistent semantics, but they are recorded in the inode as > > the number of links to the file the inode holds information on. Therefor > > any admin who is worth the money they receive for doing their task will > > know that if the number of links to a file is greater than one another > > hard link must exist. Searching the filesystem for another name > > referring the same inode is then not a really hard thing to do... > > Uh, I know a lot of admins that I consider 'worth their salt' who don't > check link counts (or maybe even notice them in an 'ls -l') before > removing a file. I don't think system upgrade scripts do it either. And "checking" still allows for race conditions. Especially when automated. And I agree that checking should not be necessary. > > Have a look at ls -l `which vi view ex` and think again about what hard > > links contribute (then again similar functionality might be constructed > > using soft-links; but they are much harder to administrate (read: keep > > under control)) > > Symlinks do not prevent the original binary from being unavailable. Please > remember that files don't really go away until all links are zero and no > more filedescs are open on them. Hey, if 'the founders' had meant for > symlinks to be used over hard links, there would have been an 'ls -h' > flag, right? 8{) Symlinks don't prevent the filedesc behavior from happening. They do not allow for the refcount, but the solution that comes to mind is actually more intuitive: mv vi vi-bin ln -s vi-bin vi ln -s vi-bin view Now you replace the one vi-bin binary and all of vi is upgraded. And it's easy to see what files are linked to other files--with hard links it can be quite hard. I'm just not sure that the consistency issues raised by hard links justify the meager benefits. > > Just my 0.02 euro. > > This means it's euro-pinion? What's the conversion rate? - Jy@ Damned if I know, and I'm English. (Of course, I'm English but living in the US :-). But clearly a European point is far better.. or something. Robert N Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: 03 01 DD 8E 15 67 48 73 25 6D 10 FC EC 68 C1 1C Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ Safeport Network Services http://www.safeport.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Mar 14 11:16:18 1999 Delivered-To: freebsd-security@freebsd.org Received: from woodstock (lakertya-1-70.mdm.mkt.execpc.com [169.207.118.70]) by hub.freebsd.org (Postfix) with ESMTP id E4E5915038 for ; Sun, 14 Mar 1999 11:16:13 -0800 (PST) (envelope-from hamilton@pobox.com) Received: from pobox.com (localhost [127.0.0.1]) by woodstock (Postfix) with ESMTP id 53FE63E; Sun, 14 Mar 1999 13:15:42 -0600 (CST) To: Peter Jeremy Cc: robert+freebsd@cyrus.watson.org, freebsd-security@FreeBSD.ORG Subject: Re: ACL's In-reply-to: Your message of "Sun, 14 Mar 1999 20:07:28 +1000." <99Mar14.195521est.40346@border.alcanet.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 14 Mar 1999 13:15:42 -0600 From: Jon Hamilton Message-Id: <19990314191542.53FE63E@woodstock> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <99Mar14.195521est.40346@border.alcanet.com.au>, Peter Jeremy wrote: } Robert Watson wrote: } >BTW, I'd really like to get rid of hard links -- they allow users to } >retain copies of setuid files after the owner thinks they are deleted. } } This strikes me as overkill. Why not just change either rm(1) or } unlink(2) to remove set[gu]id bits on executables? This would have } the same net effect and the behaviour can probably be justified. It would have to be an option and not the default behavior, otherwise you'd have a real mess when you really did want to delete just one link to a file and leave the rest alone. -- Jon Hamilton hamilton@pobox.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Mar 14 11:16:23 1999 Delivered-To: freebsd-security@freebsd.org Received: from woodstock (lakertya-1-70.mdm.mkt.execpc.com [169.207.118.70]) by hub.freebsd.org (Postfix) with ESMTP id 0CD0415038 for ; Sun, 14 Mar 1999 11:16:13 -0800 (PST) (envelope-from hamilton@pobox.com) Received: from pobox.com (localhost [127.0.0.1]) by woodstock (Postfix) with ESMTP id 804833F; Sun, 14 Mar 1999 13:15:47 -0600 (CST) To: Robert Watson Cc: Peter Jeremy , freebsd-security@FreeBSD.ORG Subject: Re: ACL's In-reply-to: Your message of "Sun, 14 Mar 1999 12:24:43 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 14 Mar 1999 13:15:47 -0600 From: Jon Hamilton Message-Id: <19990314191547.804833F@woodstock> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message , Robert Watson wrote: } On Sun, 14 Mar 1999, Peter Jeremy wrote: } } > Robert Watson wrote: } > } > >I.e., user creates a hard link to /usr/sbin/somesetuidbin to } > >/usr/tmp/mytemp. } > } > Normal users shouldn't have write permission anywhere on a partition } > containing system binaries - this also removes the problem. (Note } > that /usr/tmp is accessible only by root under FreeBSD). } } But many common FS arrangements do use the same partition for a } world-writable directory and the binaries. For example: } } /var on /usr/var (/var has /var/tmp) } /usr/local/ on /usr (The tex port requires a world-writable temp } directory) } /tmp on / (/sbin is usually on /; default install I believe) } /home on /usr/home (default install I believe) } } I like the idea of the FS namespace having consistent } semantics--counter-intuitive security behavior like "the system is } relatively secure as long as you don't partition the system in any way } that allows these files to be on the same partition as these files..." } seems best to be avoided. } } I think hard links are neat, et al, but I really don't think they add any } new useful functionality above symlinks, and they can certainly introduce } new problems. They save a little disk space here and there (as long as } you don't recursive move anything)... Symbolic links are a nightmare if you move things around. They also won't work across chroot boundaries, and can cause problems across NFS particularly in environments using the automounter -- if you use absolute symbolic links (i.e. ones which go through /) you get a surprise when someone on a remote workstation tries to use them and they try to reference / on the _remote_ machine. Use relative symbolic links and you may get surprises too. -- Jon Hamilton hamilton@pobox.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Mar 14 12:16:38 1999 Delivered-To: freebsd-security@freebsd.org Received: from host07.rwsystems.net (kasie.rwsystems.net [209.197.192.103]) by hub.freebsd.org (Postfix) with ESMTP id C601B14F24 for ; Sun, 14 Mar 1999 12:16:35 -0800 (PST) (envelope-from jwyatt@RWSystems.net) Received: from kasie.rwsystems.net([209.197.192.103]) (3278 bytes) by host07.rwsystems.net via sendmail with P:esmtp/R:bind_hosts/T:inet_zone_bind_smtp (sender: ) id for ; Sun, 14 Mar 1999 13:46:14 -0600 (CST) (Smail-3.2.0.104 1998-Nov-20 #1 built 1998-Dec-24) Date: Sun, 14 Mar 1999 13:46:13 -0600 (CST) From: James Wyatt To: freebsd-security@FreeBSD.ORG Subject: Re: ACL's In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 14 Mar 1999, Robert Watson wrote: > On Sun, 14 Mar 1999, Peter Jeremy wrote: > > Normal users shouldn't have write permission anywhere on a partition > > containing system binaries - this also removes the problem. (Note > > that /usr/tmp is accessible only by root under FreeBSD). > > But many common FS arrangements do use the same partition for a > world-writable directory and the binaries. For example: > > /var on /usr/var (/var has /var/tmp) > /usr/local/ on /usr (The tex port requires a world-writable temp > directory) > /tmp on / (/sbin is usually on /; default install I believe) > /home on /usr/home (default install I believe) For /tmp and /home, these are best as separate filesystems if you have regular users, IMHO. For /var/tmp, maybe there is a good use for a symlink? I'm sorry, but I consider making a world writable directory under /usr/local/ simply *broken*. A symlink would suffice here until the port or package or application folks could be made aware of the sysadmin implications of this behavior (the sudo folks got it right). > I like the idea of the FS namespace having consistent > semantics--counter-intuitive security behavior like "the system is > relatively secure as long as you don't partition the system in any way > that allows these files to be on the same partition as these files..." > seems best to be avoided. Yes, but it's portable. 8{) Some of us have been doing it since we had BSD on the VAXen. Some commercial Unixes (Uni?) ship that way. I also like the idea of a small root filesys and extra /tmp filesys as it moves us closer to a RO root filesys. It makes root backups quicker. In fact, it would be a nice change to the 'auto defaults' disk partitioning portion of our install. > I think hard links are neat, et al, but I really don't think they add any > new useful functionality above symlinks, and they can certainly introduce > new problems. They save a little disk space here and there (as long as > you don't recursive move anything)... Symlinks also introduce their own problems. They can point to *nothing* when hard links can't. (esp. post-fsck!) Symlinks also burn inodes and more filesystem space. They are a *real* headache and performance sink on news filesystems. Of course, having worked on *nix systems that had hard links, but no symlinks, I may be biased... I also have used them to do filesystem databases (each directory is an index with a link to the real data nugget. Fast, but table-joins by comparing inodes was tough... 8{( Anyone else remember the UseNet wag who said "Symlinks can turn your filesystem tree into a bramblebush."? Rich Salz, perhaps? - Jy@ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Mar 14 12:26:39 1999 Delivered-To: freebsd-security@freebsd.org Received: from phoenix.volant.org (phoenix.volant.org [205.179.79.193]) by hub.freebsd.org (Postfix) with ESMTP id A689E1501E for ; Sun, 14 Mar 1999 12:26:09 -0800 (PST) (envelope-from patl@phoenix.volant.org) Received: from asimov.phoenix.volant.org ([205.179.79.65]) by phoenix.volant.org with smtp (Exim 1.92 #8) id 10MHSJ-00061u-00; Sun, 14 Mar 1999 12:25:51 -0800 Received: from localhost by asimov.phoenix.volant.org (SMI-8.6/SMI-SVR4) id MAA09395; Sun, 14 Mar 1999 12:25:43 -0800 Date: Sun, 14 Mar 1999 12:25:43 -0800 (PST) From: patl@phoenix.volant.org Reply-To: patl@phoenix.volant.org Subject: Re: ACL's To: Robert Watson Cc: freebsd-security@FreeBSD.ORG In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > There seems to be some contradiction here: you want users without > extensive security experience and unwilling to look at nightly security > mailings to know how to partition systems in the manner you describe? Sysadmins that aren't willing to spend a few seconds a day reading their nightly security mailings deserve whatever they get. > Recursive cp? (The intuitive, simple, *man page recommended* way to copy > a directory from one hard disk to another?) Then the man page needs to be fixed to recommend something that actually works correctly. > > Uh, I know a lot of admins that I consider 'worth their salt' who don't > > check link counts (or maybe even notice them in an 'ls -l') before > > removing a file. I don't think system upgrade scripts do it either. > > And "checking" still allows for race conditions. Especially when > automated. And I agree that checking should not be necessary. I'm surprised that nobody has suggested using 'rm -P' to overwrite the file's contents. It seems like it might also be useful to have one or more new options to rm related to link count checking. Perhaps one that will only delete if the link count is 1, otherwise issue an error. (It can detect a lost race condition by opening the file, doing the unlink, then checking the link count on the open fd before closing.) Or perhaps an option that will only do the overwrite if the link count was one. (Otherwise issuing an error. Force overwrite via the -f option.) -Pat To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Mar 14 12:40:54 1999 Delivered-To: freebsd-security@freebsd.org Received: from fledge.watson.org (FLEDGE.RES.CMU.EDU [128.2.93.229]) by hub.freebsd.org (Postfix) with ESMTP id 096D315351 for ; Sun, 14 Mar 1999 12:40:47 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id PAA06358; Sun, 14 Mar 1999 15:40:24 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Sun, 14 Mar 1999 15:40:24 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Jon Hamilton Cc: Peter Jeremy , freebsd-security@FreeBSD.ORG Subject: Re: ACL's In-Reply-To: <19990314191547.804833F@woodstock> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 14 Mar 1999, Jon Hamilton wrote: > In message , Robert > Watson wrote: > } On Sun, 14 Mar 1999, Peter Jeremy wrote: > } > } > Robert Watson wrote: > } > > } > >I.e., user creates a hard link to /usr/sbin/somesetuidbin to > } > >/usr/tmp/mytemp. > } > > } > Normal users shouldn't have write permission anywhere on a partition > } > containing system binaries - this also removes the problem. (Note > } > that /usr/tmp is accessible only by root under FreeBSD). > } > } But many common FS arrangements do use the same partition for a > } world-writable directory and the binaries. For example: > } > } /var on /usr/var (/var has /var/tmp) > } /usr/local/ on /usr (The tex port requires a world-writable temp > } directory) > } /tmp on / (/sbin is usually on /; default install I believe) > } /home on /usr/home (default install I believe) > } > } I like the idea of the FS namespace having consistent > } semantics--counter-intuitive security behavior like "the system is > } relatively secure as long as you don't partition the system in any way > } that allows these files to be on the same partition as these files..." > } seems best to be avoided. > } > } I think hard links are neat, et al, but I really don't think they add any > } new useful functionality above symlinks, and they can certainly introduce > } new problems. They save a little disk space here and there (as long as > } you don't recursive move anything)... > > Symbolic links are a nightmare if you move things around. They also > won't work across chroot boundaries, and can cause problems across NFS > particularly in environments using the automounter -- if you use > absolute symbolic links (i.e. ones which go through /) you get a surprise > when someone on a remote workstation tries to use them and they try to > reference / on the _remote_ machine. Use relative symbolic links and > you may get surprises too. No matter what behavior we choose, we get some amount of inconsistency--this is the effect of violating the one-name<->one-object behavior. However, my argument is that hard links result in security concerns that symlinks will not result in--e.g., a certain set of race conditions and the ability of a user to preserve binaries that the owner does not want preserved. And that it does this in a counter-intuitive way across partitions which are (normally) not visible distinctions from the point of view of the user. Symlinks have consistent behavior across the entire namespace, and leaving aside the garbage collection issue, provide pretty much all functionality hardlinks do. This garbage-collection issue is in fact the change that I want: the names referencing an object should obey the semantics required by the controller of the original object, not of anyone who is able to read it at any point in its history. Symlinks allow me to revoke access to an object trivially, and consistently with the hierarchal directory behavior. And since files in UNIX convey capabilities, this is actually extremely important. In response to the absolute symlink concern: this is why in my example (see some email or another) I used only relative symlinks. You'll find that, given the arbitrary way partitioning occurs, this is the only useful way to manage hard links also: the user can specify any directory-separated partioning scheme they choose when they install, and most of them make sense. Removing hard links helps us in a number of ways: it allows for a unique name relative to a partition for a file (great for auditing and TPE); it allows atomicity and reliability for deletion, along with prevention of inode hijacking. It provides a more consistent view of the FS to the average user: symlinks work across partitions, network file systems, etc. It allows a unique set of permissions to be evaluated for a file, ensuring that a common set are applied to all users. It allows revocation of file access to be ensured by the owner. As with all aliasing, symlinks can result in surprises. I argue that they result in fewer surprises; in particular, fewer security-related surprises. How about sysctl vfs.allow_hardlinks? :-) If there isn't one already, I'll submit patches. It would restrict only creation of new hard links. Plus possibly a utility to flatten existing hard links by a) copying the file to a temporary location, b) unlinking the original, and c) renaming the copy back to the original name, for any file with >1 references. Robert N Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: 03 01 DD 8E 15 67 48 73 25 6D 10 FC EC 68 C1 1C Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ Safeport Network Services http://www.safeport.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Mar 14 12:56: 5 1999 Delivered-To: freebsd-security@freebsd.org Received: from fledge.watson.org (FLEDGE.RES.CMU.EDU [128.2.93.229]) by hub.freebsd.org (Postfix) with ESMTP id 6A3BC14E7E for ; Sun, 14 Mar 1999 12:56:03 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id PAA06428; Sun, 14 Mar 1999 15:55:41 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Sun, 14 Mar 1999 15:55:41 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: patl@phoenix.volant.org Cc: freebsd-security@FreeBSD.ORG Subject: Re: ACL's In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 14 Mar 1999 patl@phoenix.volant.org wrote: > > There seems to be some contradiction here: you want users without > > extensive security experience and unwilling to look at nightly security > > mailings to know how to partition systems in the manner you describe? > > Sysadmins that aren't willing to spend a few seconds a day reading their > nightly security mailings deserve whatever they get. My point exactly :-). I want simple behavior that is consistent; something that doesn't require users to be familiar with the caveats of hard links to understand. I bet the majority of users have no idea that their old setuid binaries can be hijacked, even after the OS is upgraded. But they can, because the majority of users have home directories on their /usr partition. > > Recursive cp? (The intuitive, simple, *man page recommended* way to copy > > a directory from one hard disk to another?) > > Then the man page needs to be fixed to recommend something that actually > works correctly. It seems counter-intuitive that the copy utility with the recursive flag be the incorrect way to recursively copy :-). > > > Uh, I know a lot of admins that I consider 'worth their salt' who don't > > > check link counts (or maybe even notice them in an 'ls -l') before > > > removing a file. I don't think system upgrade scripts do it either. > > > > And "checking" still allows for race conditions. Especially when > > automated. And I agree that checking should not be necessary. > > I'm surprised that nobody has suggested using 'rm -P' to overwrite > the file's contents. Nasty if it's mmap'd anywhere :-). Shared libraries aren't so happy, I think. :-) Probably the closest thing to the correct behavior is open() unlink() if (link count > 0) fchmod() to remove the setuid bit. > It seems like it might also be useful to have one or more new options > to rm related to link count checking. Perhaps one that will only > delete if the link count is 1, otherwise issue an error. (It can > detect a lost race condition by opening the file, doing the unlink, > then checking the link count on the open fd before closing.) Or perhaps > an option that will only do the overwrite if the link count was one. > (Otherwise issuing an error. Force overwrite via the -f option.) We already have multiply-hard-linked setuid binaries like passwd. This error would turn up whenever dealing with them. I think my conclusion is this: hard links are too burnt into the minds of my unix brethren to be removed today. Perhaps I'll bring it up in another year or two. In the mean time, I'll add a way to disable it (default to enabled), and advise that folks who want secure behavior, and don't want to rely on bizarre partitioning to guarantee that, use this flag. Is there any legitimate objection to this suggestion? The only one that comes to mind is the installworld behavior that hard links it in in the first place. I know of few people that actually even use hard links. :-) They're too non-portable due to directory/partition problems, especially in the world of scalable distributed file systems (AFS, Coda, DFS, etc) where two directories may rely on different servers, not just different partitions on the local system. Robert N Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: 03 01 DD 8E 15 67 48 73 25 6D 10 FC EC 68 C1 1C Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ Safeport Network Services http://www.safeport.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Mar 14 13:16:20 1999 Delivered-To: freebsd-security@freebsd.org Received: from woodstock (lakertya-1-70.mdm.mkt.execpc.com [169.207.118.70]) by hub.freebsd.org (Postfix) with ESMTP id 4914814E87 for ; Sun, 14 Mar 1999 13:16:16 -0800 (PST) (envelope-from hamilton@pobox.com) Received: from pobox.com (localhost [127.0.0.1]) by woodstock (Postfix) with ESMTP id E37313E; Sun, 14 Mar 1999 15:15:56 -0600 (CST) To: Robert Watson Cc: Peter Jeremy , freebsd-security@FreeBSD.ORG Subject: Re: ACL's In-reply-to: Your message of "Sun, 14 Mar 1999 15:40:24 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 14 Mar 1999 15:15:56 -0600 From: Jon Hamilton Message-Id: <19990314211556.E37313E@woodstock> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org } > } I like the idea of the FS namespace having consistent } > } semantics--counter-intuitive security behavior like "the system is } > } relatively secure as long as you don't partition the system in any way } > } that allows these files to be on the same partition as these files..." } > } seems best to be avoided. } > } } > } I think hard links are neat, et al, but I really don't think they add any } > } new useful functionality above symlinks, and they can certainly introduce } > } new problems. They save a little disk space here and there (as long as } > } you don't recursive move anything)... } > } > Symbolic links are a nightmare if you move things around. They also } > won't work across chroot boundaries, and can cause problems across NFS } > particularly in environments using the automounter -- if you use } > absolute symbolic links (i.e. ones which go through /) you get a surprise } > when someone on a remote workstation tries to use them and they try to } > reference / on the _remote_ machine. Use relative symbolic links and } > you may get surprises too. } } No matter what behavior we choose, we get some amount of } inconsistency--this is the effect of violating the one-name<->one-object } behavior. However, my argument is that hard links result in security } concerns that symlinks will not result in--e.g., a certain set of race } conditions and the ability of a user to preserve binaries that the owner } does not want preserved. And that it does this in a counter-intuitive way The race condition argument actually works *against* symbolic links. } across partitions which are (normally) not visible distinctions from the } point of view of the user. Symlinks have consistent behavior across the } entire namespace, and leaving aside the garbage collection issue, provide } pretty much all functionality hardlinks do. No, they provide all the functionality that hardlinks do that *you* care about. Not every installation is used the same way, and you're simply not going to be able to just do away with hard links by fiat; too many people and things rely upon them. } This garbage-collection issue is in fact the change that I want: the names } referencing an object should obey the semantics required by the controller } of the original object, not of anyone who is able to read it at any point } in its history. Symlinks allow me to revoke access to an object } trivially, and consistently with the hierarchal directory behavior. And } since files in UNIX convey capabilities, this is actually extremely } important. Nobody is forcing you to use hard links; if you like symbolic links, then use them and your problems are over. } Removing hard links helps us in a number of ways: it allows for a unique } name relative to a partition for a file (great for auditing and TPE); it } allows atomicity and reliability for deletion, along with prevention of The deletion argument doesn't hold water either; you still have to check whether the name you know something as (and the name you intend to delete) is a symlink or the original file. } inode hijacking. It provides a more consistent view of the FS to the } average user: symlinks work across partitions, network file systems, etc. } It allows a unique set of permissions to be evaluated for a file, ensuring } that a common set are applied to all users. It allows revocation of file } access to be ensured by the owner. So do hard links; simply chmod any one of the links and the others follow. } As with all aliasing, symlinks can result in surprises. I argue that they } result in fewer surprises; in particular, fewer security-related } surprises. I simply don't buy that argument. } How about sysctl vfs.allow_hardlinks? :-) If there isn't one already, I wouldn't have any argument against that, provided that the default is to leave them on. } I'll submit patches. It would restrict only creation of new hard links. } Plus possibly a utility to flatten existing hard links by a) copying the } file to a temporary location, b) unlinking the original, and c) renaming } the copy back to the original name, for any file with >1 references. Ick ick ick! :) -- Jon Hamilton hamilton@pobox.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Mar 14 13:32:44 1999 Delivered-To: freebsd-security@freebsd.org Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by hub.freebsd.org (Postfix) with ESMTP id A28B71546C for ; Sun, 14 Mar 1999 13:31:26 -0800 (PST) (envelope-from wsanchez@scv2.apple.com) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.8.5/8.8.5) with ESMTP id NAA50290 for ; Sun, 14 Mar 1999 13:29:02 -0800 Received: from scv2.apple.com (scv2.apple.com) by mailgate1.apple.com (mailgate1.apple.com- SMTPRS 2.0.15) with ESMTP id ; Sun, 14 Mar 1999 13:28:56 -0800 Received: from joliet-jake (joliet-jake.apple.com [17.202.40.140]) by scv2.apple.com (8.9.3/8.9.3) with SMTP id NAA10220; Sun, 14 Mar 1999 13:28:55 -0800 Message-Id: <199903142128.NAA10220@scv2.apple.com> To: Robert Watson Subject: Re: ACL's Cc: Thomas Valentino Crimi , freebsd-security@FreeBSD.ORG In-Reply-To: Date: Sun, 14 Mar 1999 13:28:52 -0800 From: Wilfredo Sanchez Reply-To: wsanchez@apple.com X-Mailer: by Apple MailViewer (2.106) Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org | BTW, I'd really like to get rid of hard links -- they allow users to | retain copies of setuid files after the owner thinks they are deleted. | I.e., user creates a hard link to /usr/sbin/somesetuidbin to | /usr/tmp/mytemp. Now the admin upgrades the machine, thinking they have | removed the risk of the now known buggy somesetuidbin. Is there any reason (other than "it always has been so") why users should be allowed to create hard links to files they don't own? -Fred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Mar 14 13:36:18 1999 Delivered-To: freebsd-security@freebsd.org Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by hub.freebsd.org (Postfix) with ESMTP id 40AAD15208 for ; Sun, 14 Mar 1999 13:36:05 -0800 (PST) (envelope-from jared@puck.nether.net) Received: (from jared@localhost) by puck.nether.net (8.9.3/8.7.3) id QAA23041; Sun, 14 Mar 1999 16:35:50 -0500 (envelope-from jared) Date: Sun, 14 Mar 1999 16:35:50 -0500 From: Jared Mauch To: Wilfredo Sanchez Cc: Robert Watson , Thomas Valentino Crimi , freebsd-security@FreeBSD.ORG Subject: Re: ACL's Message-ID: <19990314163550.C20987@puck.nether.net> Mail-Followup-To: Wilfredo Sanchez , Robert Watson , Thomas Valentino Crimi , freebsd-security@FreeBSD.ORG References: <199903142128.NAA10220@scv2.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <199903142128.NAA10220@scv2.apple.com>; from Wilfredo Sanchez on Sun, Mar 14, 1999 at 01:28:52PM -0800 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, Mar 14, 1999 at 01:28:52PM -0800, Wilfredo Sanchez wrote: > | BTW, I'd really like to get rid of hard links -- they allow users to > | retain copies of setuid files after the owner thinks they are deleted. > | I.e., user creates a hard link to /usr/sbin/somesetuidbin to > | /usr/tmp/mytemp. Now the admin upgrades the machine, thinking > they have > | removed the risk of the now known buggy somesetuidbin. > > Is there any reason (other than "it always has been so") why users > should be allowed to create hard links to files they don't own? I personally can't think of one. What would be interesting would be to see a kernel option for it, have some folks test it, and see what might break from this going on. - Jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Mar 14 13:40:15 1999 Delivered-To: freebsd-security@freebsd.org Received: from relay.acadiau.ca (relay.acadiau.ca [131.162.2.90]) by hub.freebsd.org (Postfix) with ESMTP id C7D5114C3D for ; Sun, 14 Mar 1999 13:40:11 -0800 (PST) (envelope-from 026809r@dragon.acadiau.ca) Received: from dragon.acadiau.ca (dragon.acadiau.ca [131.162.1.79]) by relay.acadiau.ca (8.8.5/8.8.5) with ESMTP id RAA29135 for ; Sun, 14 Mar 1999 17:39:20 -0400 (AST) Received: from localhost (026809r@localhost) by dragon.acadiau.ca (8.8.8+Sun/8.8.8) with ESMTP id RAA03126 for ; Sun, 14 Mar 1999 17:39:20 -0400 (AST) Date: Sun, 14 Mar 1999 17:39:20 -0400 (AST) From: Michael Richards <026809r@dragon.acadiau.ca> X-Sender: 026809r@dragon To: security@freebsd.org Subject: Getting rid of hard links? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi. Just my $0.02. I hope you don't decide to get rid of hard links. We do a lot of stuff that requires hard links as a result of custom coded databases. I'm not familliar with the internals as I did not write it, however I am told our system can be ported over to OpenBSD with less trouble than fixing whatever requires the hard links. FreeBSD has served us well and I hope we don't have to abandon it :( It seems to me that the changes to rm/cp would be the smartest route because it wouldn't break anything and would seemingly address most of the issues brought up. -Michael To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Mar 14 13:40:18 1999 Delivered-To: freebsd-security@freebsd.org Received: from phoenix.volant.org (phoenix.volant.org [205.179.79.193]) by hub.freebsd.org (Postfix) with ESMTP id 54F8714D79 for ; Sun, 14 Mar 1999 13:40:16 -0800 (PST) (envelope-from patl@phoenix.volant.org) Received: from asimov.phoenix.volant.org ([205.179.79.65]) by phoenix.volant.org with smtp (Exim 1.92 #8) id 10MIc1-0006du-00; Sun, 14 Mar 1999 13:39:57 -0800 Received: from localhost by asimov.phoenix.volant.org (SMI-8.6/SMI-SVR4) id NAA09421; Sun, 14 Mar 1999 13:39:48 -0800 Date: Sun, 14 Mar 1999 13:39:48 -0800 (PST) From: patl@phoenix.volant.org Reply-To: patl@phoenix.volant.org Subject: Re: ACL's To: Robert Watson Cc: freebsd-security@FreeBSD.ORG In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > On Sun, 14 Mar 1999 patl@phoenix.volant.org wrote: > > > > There seems to be some contradiction here: you want users without > > > extensive security experience and unwilling to look at nightly security > > > mailings to know how to partition systems in the manner you describe? > > > > Sysadmins that aren't willing to spend a few seconds a day reading their > > nightly security mailings deserve whatever they get. > > My point exactly :-). I want simple behavior that is consistent; > something that doesn't require users to be familiar with the caveats of > hard links to understand. I bet the majority of users have no idea that > their old setuid binaries can be hijacked, even after the OS is upgraded. > But they can, because the majority of users have home directories on their > /usr partition. No, that's not my point. My point is that anyone who is going to admin a system that other users can log into had damn well better learn some minimal security precautions. Like reading and understanding the nightly security report. Holding their hand by duct-taping foam rubber over a couple of sharp edges isn't doing them any favors at all. It's just giving them a false sense of security while removing a -very- useful and long-standing feature from the OS. My further point is that no sysadmin who has the slightest concern about security can simply rely on the system to keep them safe. Monitoring the logs and reports is a vital part of the sysadmin's job. Any admin who ignores the logs and reports is asking for a breach; and deserves whatever hardship that breach generates. > > > Recursive cp? (The intuitive, simple, *man page recommended* way to > > > copy a directory from one hard disk to another?) > > > > Then the man page needs to be fixed to recommend something that actually > > works correctly. > > It seems counter-intuitive that the copy utility with the recursive flag > be the incorrect way to recursively copy :-). Most of life is counter-intuitive. > > I'm surprised that nobody has suggested using 'rm -P' to overwrite > > the file's contents. > > Nasty if it's mmap'd anywhere :-). Shared libraries aren't so happy, I > think. :-) Probably the closest thing to the correct behavior is > > open() > unlink() > if (link count > 0) > fchmod() > > to remove the setuid bit. Of course it zaps anything that had the file open. That's part of the idea. It ensures that the file can't be resurrected elsewhere by some program hanging around with it open just to keep the inode alive. > > It seems like it might also be useful to have one or more new options > > to rm related to link count checking. Perhaps one that will only > > delete if the link count is 1, otherwise issue an error. (It can > > detect a lost race condition by opening the file, doing the unlink, > > then checking the link count on the open fd before closing.) Or perhaps > > an option that will only do the overwrite if the link count was one. > > (Otherwise issuing an error. Force overwrite via the -f option.) > > We already have multiply-hard-linked setuid binaries like passwd. This > error would turn up whenever dealing with them. That's why it's an optional flag. > I think my conclusion is this: hard links are too burnt into the minds of > my unix brethren to be removed today. Perhaps I'll bring it up in another > year or two. In the mean time, I'll add a way to disable it (default to > enabled), and advise that folks who want secure behavior, and don't want > to rely on bizarre partitioning to guarantee that, use this flag. Is > there any legitimate objection to this suggestion? The only one that > comes to mind is the installworld behavior that hard links it in in the > first place. Hard links solve various problems in a fairly reasonable manner. The potential for their abuse is no excuse for the loss of functionality that would come from removing them. Removing hard link capability just isn't an elegant solution. The schg/uchg flags prevent hard links on a file-by file bases. That is a much more elegant approach. You might argue that it would be even better to have a separate no-links flag. > I know of few people that actually even use hard links. :-) They're too > non-portable due to directory/partition problems, especially in the world > of scalable distributed file systems (AFS, Coda, DFS, etc) where two > directories may rely on different servers, not just different partitions > on the local system. You must have a unique set of unix-using associates... I'd also like to point out that hard links are primarily used within a single directory; or within sibling directories. -Pat To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Mar 14 14: 6:14 1999 Delivered-To: freebsd-security@freebsd.org Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.26.10.9]) by hub.freebsd.org (Postfix) with ESMTP id DDD561567A for ; Sun, 14 Mar 1999 14:06:06 -0800 (PST) (envelope-from bde@godzilla.zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.8.7) id JAA20202; Mon, 15 Mar 1999 09:05:47 +1100 Date: Mon, 15 Mar 1999 09:05:47 +1100 From: Bruce Evans Message-Id: <199903142205.JAA20202@godzilla.zeta.org.au> To: patl@phoenix.volant.org, robert+freebsd@cyrus.watson.org Subject: Re: ACL's Cc: freebsd-security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> > Recursive cp? (The intuitive, simple, *man page recommended* way to copy >> > a directory from one hard disk to another?) >> >> Then the man page needs to be fixed to recommend something that actually >> works correctly. > >It seems counter-intuitive that the copy utility with the recursive flag >be the incorrect way to recursively copy :-). cp -pR (and thus mv across file systems) are broken (non-POSIX.2 conformant). They snap hard links and don't preserve directory timestamps. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Mar 14 14:42:55 1999 Delivered-To: freebsd-security@freebsd.org Received: from trooper.velocet.ca (host-034.canadiantire.ca [209.146.201.34]) by hub.freebsd.org (Postfix) with ESMTP id BF0BD14C82 for ; Sun, 14 Mar 1999 14:42:52 -0800 (PST) (envelope-from dgilbert@trooper.velocet.ca) Received: (from dgilbert@localhost) by trooper.velocet.ca (8.8.7/8.8.7) id RAA00297; Sun, 14 Mar 1999 17:40:00 -0500 (EST) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14060.15038.71703.849469@trooper.velocet.ca> Date: Sun, 14 Mar 1999 17:39:58 -0500 (EST) To: Michael Richards <026809r@dragon.acadiau.ca> Cc: security@FreeBSD.ORG Subject: Getting rid of hard links? In-Reply-To: References: X-Mailer: VM 6.62 under Emacs 19.34.2 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >>>>> "Michael" == Michael Richards <026809r@dragon.acadiau.ca> writes: Michael> the internals as I did not write it, however I am told our Michael> system can be ported over to OpenBSD with less trouble than Michael> fixing whatever requires the hard links. FreeBSD has served Michael> us well and I hope we don't have to abandon it :( Similarly, I have made a lot of diskless servers (100Mb networking is faster than cheep local disk for swap) and use hard links for each root extensively. Michael> It seems to me that the changes to rm/cp would be the Michael> smartest route because it wouldn't break anything and would Michael> seemingly address most of the issues brought up. Fixing the problem instead of the symptom? Maybe links (hard and soft) should only have the permissions that the user can create subject to a mask of permissions on the origional file? Ie: I can't create a link to a suid file that is suid unless I could create the suid file. Dave. -- ============================================================================ |David Gilbert, Velocet Communications. | Two things can only be | |Mail: dgilbert@velocet.net | equal if and only if they | |http://www.velocet.net/~dgilbert | are precisely opposite. | =========================================================GLO================ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Mar 14 15: 3:44 1999 Delivered-To: freebsd-security@freebsd.org Received: from fledge.watson.org (FLEDGE.RES.CMU.EDU [128.2.93.229]) by hub.freebsd.org (Postfix) with ESMTP id 9800015002 for ; Sun, 14 Mar 1999 15:03:00 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id SAA06934; Sun, 14 Mar 1999 18:02:36 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Sun, 14 Mar 1999 18:02:36 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Wilfredo Sanchez Cc: Thomas Valentino Crimi , freebsd-security@FreeBSD.ORG Subject: Re: ACL's In-Reply-To: <199903142128.NAA10220@scv2.apple.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 14 Mar 1999, Wilfredo Sanchez wrote: > | BTW, I'd really like to get rid of hard links -- they allow users to > | retain copies of setuid files after the owner thinks they are deleted. > | I.e., user creates a hard link to /usr/sbin/somesetuidbin to > | /usr/tmp/mytemp. Now the admin upgrades the machine, thinking > they have > | removed the risk of the now known buggy somesetuidbin. > > Is there any reason (other than "it always has been so") why users > should be allowed to create hard links to files they don't own? This variation on the restriction theme seems quite promising. Off hand, I don't know of any linking behavior in the base system that relies on renaming files owned by other users (except rename, and that is a separate syscall). Most of the database applications people are mentioning (including news) probably remain within the scope of a single user, I would guess? And a number of the attacks of interest are related to setuid or other files owned by different users (specifically interesting ones). It seems to address well my concern that users cannot revoke access to a file. Now they can be sure that rename() or chmod() followed by revoke() to address data files, and simply unlink to dispose of a setuid file. Setuid is presumably only of interest on open() so continued access to an already instantied setuid session is probably fine. Rename could be induced to look like a hard link by causing a system crash/power failure at an appropriate point in the rename procedure, I would guess. But that's probably not in the scope of the security protections we're addressing at this point. :-) So, does anyone have any examples of situations handled incorrectly/badly by allowing only the owner of a file to link() it? Robert N Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: 03 01 DD 8E 15 67 48 73 25 6D 10 FC EC 68 C1 1C Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ Safeport Network Services http://www.safeport.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Mar 14 16:52: 9 1999 Delivered-To: freebsd-security@freebsd.org Received: from phoenix.volant.org (phoenix.volant.org [205.179.79.193]) by hub.freebsd.org (Postfix) with ESMTP id E05491504F for ; Sun, 14 Mar 1999 16:52:07 -0800 (PST) (envelope-from patl@phoenix.volant.org) Received: from asimov.phoenix.volant.org ([205.179.79.65]) by phoenix.volant.org with smtp (Exim 1.92 #8) id 10MLbh-0000Uv-00; Sun, 14 Mar 1999 16:51:49 -0800 Received: from localhost by asimov.phoenix.volant.org (SMI-8.6/SMI-SVR4) id QAA09491; Sun, 14 Mar 1999 16:51:45 -0800 Date: Sun, 14 Mar 1999 16:51:45 -0800 (PST) From: patl@phoenix.volant.org Reply-To: patl@phoenix.volant.org Subject: Re: ACL's To: Robert Watson Cc: freebsd-security@FreeBSD.ORG In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > So, does anyone have any examples of situations handled incorrectly/badly > by allowing only the owner of a file to link() it? I'm sure there have been times when that would have caused an irritating need to su. How would you feel about relaxing that to owner or anyone with write permission? (And I suspect I'd still want that to be a sysctl flag that could revert to current behavour.) -Pat To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Mar 14 17:25:58 1999 Delivered-To: freebsd-security@freebsd.org Received: from fledge.watson.org (FLEDGE.RES.CMU.EDU [128.2.93.229]) by hub.freebsd.org (Postfix) with ESMTP id C618815AB0 for ; Sun, 14 Mar 1999 17:25:47 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id UAA07633; Sun, 14 Mar 1999 20:25:27 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Sun, 14 Mar 1999 20:25:27 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Wilfredo Sanchez Cc: Thomas Valentino Crimi , freebsd-security@FreeBSD.ORG Subject: Re: ACL's In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 14 Mar 1999, Robert Watson wrote: > This variation on the restriction theme seems quite promising. Off hand, > I don't know of any linking behavior in the base system that relies on > renaming files owned by other users (except rename, and that is a separate Needless to say, s/renaming/linking/ in the above line; my typing was getting ahead of my sentence. What I meant was that linking files owned by other users seemed to be unusual, except in renaming which is now supported by the rename() syscall instead. Just a (hopefully obvious) clarification. The s/owned/writable by/ change suggested sounds reasonable also. I update my request for broken features and/or security holes given this change: link(thefile, newname) will succeed only if open(thefile, O_RDWR) would have succeeded, and if open(newname, O_CREAT, 0) would have succeeded. In this manner, the following interesting behavior is restricted: a) Joe user may not hard link a setuid root binary mode 755 from /usr/sbin to /usr/home/joeuser/privatebin, as they could not have opened the binary for writing. b) Joe user may not hard link another users data file mode 644 in /usr/home/samuser/patentapplication to /usr/home/joeuser/privatedata as they could not have opened the data file for writing. The following behavior is not restricted: c) Joe user may hard link a data file they own in their home directory to another name. d) Joe user may hard link a group-writable file in another user's home if Joe user is in the group of the file. e) Root may hard link any file to any other file on the same partition. Through the addition of file system ACLs, this is really quite flexible. So we are still in search of any other real-world use that might be broken as a result of the change. Robert N Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: 03 01 DD 8E 15 67 48 73 25 6D 10 FC EC 68 C1 1C Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ Safeport Network Services http://www.safeport.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Mar 14 17:50: 0 1999 Delivered-To: freebsd-security@freebsd.org Received: from po7.andrew.cmu.edu (PO7.ANDREW.CMU.EDU [128.2.10.107]) by hub.freebsd.org (Postfix) with ESMTP id 9ACD014FFE for ; Sun, 14 Mar 1999 17:49:58 -0800 (PST) (envelope-from tcrimi+@andrew.cmu.edu) Received: (from postman@localhost) by po7.andrew.cmu.edu (8.8.5/8.8.2) id UAA02393; Sun, 14 Mar 1999 20:49:38 -0500 (EST) Received: via switchmail; Sun, 14 Mar 1999 20:49:38 -0500 (EST) Received: from unix16.andrew.cmu.edu via qmail ID ; Sun, 14 Mar 1999 20:49:17 -0500 (EST) Received: from unix16.andrew.cmu.edu via qmail ID ; Sun, 14 Mar 1999 20:49:15 -0500 (EST) Received: from mms.4.60.Jun.27.1996.03.02.53.sun4.51.EzMail.2.0.CUILIB.3.45.SNAP.NOT.LINKED.unix16.andrew.cmu.edu.sun4m.54 via MS.5.6.unix16.andrew.cmu.edu.sun4_51; Sun, 14 Mar 1999 20:49:15 -0500 (EST) Message-ID: Date: Sun, 14 Mar 1999 20:49:15 -0500 (EST) From: Thomas Valentino Crimi To: Robert Watson , Jon Hamilton Subject: Re: ACL's Cc: Peter Jeremy , freebsd-security@FreeBSD.ORG In-Reply-To: <19990314211556.E37313E@woodstock> References: <19990314211556.E37313E@woodstock> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Excerpts from FreeBSD-Security: 14-Mar-99 Re: ACL's by Jon Hamilton@pobox.com >No, they provide all the functionality that hardlinks do that *you* care >about. Not every installation is used the same way, and you're simply >not going to be able to just do away with hard links by fiat; too many >people and things rely upon them. The best would probably be to make it a mount option, same would go for ACL's themselves for that matter. Hardlinks make a lot of sense in particular partitions, but I'm hard pressed to be convinced they make sense everywhere (particuarlly as they can only SPAN a particular partition). With ACL's it would be very dependent on the implementation as to wether they should be turned on on a per-partition basis, the fact that there are dedicated permissions which could do well without ACL's means that if there is anything but negligable performance degredation using ACL's, they should be able to be turned off into a NOP for that particular partition which doens't need them. Making anything like this a kernel switch seems to almost through the machine into a 'single use' mode, which is all well for large machine shops, or those with particular interests, but it is also nice to have one machine theoretically be able to 'do it all' as far as be secure, as well as, say, be a news server. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Mar 14 19:47:16 1999 Delivered-To: freebsd-security@freebsd.org Received: from host07.rwsystems.net (kasie.rwsystems.net [209.197.192.103]) by hub.freebsd.org (Postfix) with ESMTP id A97ED14DFB for ; Sun, 14 Mar 1999 19:47:09 -0800 (PST) (envelope-from jwyatt@RWSystems.net) Received: from kasie.rwsystems.net([209.197.192.103]) (9857 bytes) by host07.rwsystems.net via sendmail with P:esmtp/R:bind_hosts/T:inet_zone_bind_smtp (sender: ) id for ; Sun, 14 Mar 1999 21:15:41 -0600 (CST) (Smail-3.2.0.104 1998-Nov-20 #1 built 1998-Dec-24) Date: Sun, 14 Mar 1999 21:15:40 -0600 (CST) From: James Wyatt To: Robert Watson Cc: The Unicorn , Thomas Valentino Crimi , freebsd-security@FreeBSD.ORG Subject: Re: ACL's In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 14 Mar 1999, Robert Watson wrote: > On Sun, 14 Mar 1999, James Wyatt wrote: > > > On Sun, 14 Mar 1999, The Unicorn wrote: > > > On Sat, Mar 13, 1999 at 07:26:52PM -0500, Robert Watson wrote: > > > > BTW, I'd really like to get rid of hard links -- they allow users to > > > > retain copies of setuid files after the owner thinks they are deleted. > > > > I.e., user creates a hard link to /usr/sbin/somesetuidbin to > > > > /usr/tmp/mytemp. Now the admin upgrades the machine, thinking they have > > > > removed the risk of the now known buggy somesetuidbin. > > > > To quote Bill The Cat: Ack! Phht! > > No! Please, No! I use arg0 in a lot of my programming when it's useful to > > have common code that does related, but different, things. (Please look at > > the boot disk, vi/ex/view/nvi/nex/nview, gzip/gunzip/zcat/gzcat, gcc/cc, > > compress/uncompress, etc...) If you want to find more, just try: > > > > find / -links +1 -type f -print | xargs ls -l | more > > symlinks, when executed, pass the symlink name as arg0. True, they just take extra space, reads, cache, etc... but not much. > > This is just too useful to most folks to save the sysadmin who doesn't > > read their nightly security mailings. It is also why I like a /tmp filesys > > (as well as a /home) filesys on machines with real users. Don't let them > > link on drives w/important binaries and don't let them vi ~/bigfile to > > fill-up /tmp and hurt everyone using '/'! Ensure, if you have one, that > > ~ftp/incoming is a separate filesys too. 8{) > > There seems to be some contradiction here: you want users without > extensive security experience and unwilling to look at nightly security > mailings to know how to partition systems in the manner you describe? I expect admins who don't usually exhaustively check files before deleting them to read mail sent to them every night. Backup admins who also get the mail (we get our customers security mail) can also read it. > What about users who use setuid so that their CGI scripts execute as their > own UID? This means having more than one user per partition is a bad > idea. No, it doesn't: we just don't have user cgi running in the same partition as the system binaries - that can be a bad idea too. No can hard link to *anything* systemwise. If I have suid-root stuff in my web tree, I should be *very* careful of it anyway as there is no retry limit or delay like telnetd. Of course I can't prevent them from symlinking to /usr/bin/su and brute forcing a crack. I get logs of that, though. > The merits of a MFS /tmp (cleared at boot, restricted in size, etc) should > not be confused with the merits of secure file system behavior. All I > want is for it to be safe for me to have a setuid binary on the same file > system as a temporary directory. File systems were not intended to be the > partitioning points for security domains -- they are for file storage as > binary blobs :-). Don't overload security characteristics onto local hard > disk arrangement. I know that this already happens somewhat, but I'd like > to try and reduce it in the name of KISS and consistency. > > Especially given how many people run with so many different partition > arrangements. Personally, on notebooks, I like to have everything except > tmp on one partition, and have tmp on MFS. This means that the slack > space from each partition is not wasted in places where it won't be needed > (not much mail delivery on my notebook). On the other hand, it doesn't > meet the requirement that each user home directory, world-writable > directory (*/tmp, texmf, etc), etc, be on a different partion :-). And it > does end up being a multi-user machine (a poor distinction except from the > point of view of performance operation in my view) because sometimes I > need to access it remotely, or give other people access to files on it. I theory, I like the idea of /tmp on a(n) MFS. It comes up clean and saves a partition. In practice, I usually have to enlarge swap about exactly as much as I saved on /tmp. I don't usually have to worry about suid programs in /tmp, or need them. In fact, prefer noexec on /tmp when I can get it... When filesystem support RO, noexec, etc. it tells me someone else must think partitioning of security by filesystem was intended - if not optimal. /tmp is used for intermediate files and scratch data as I don't do much mail routing on the laptop either - it's address changes too much. As my laptop is not usually a security risk, so I usually use just root and swap as well. I also find that I like /tmp hanging around more on the laptop than a server when I forget to save the more important intermediate files. 8{( I also don't have to hunt down users if something fills it up. > > > > target directory). Given that hard links already cause inconsistent > > > > semantics in the name space for users, and aren't properly preserved in > > > > tar, etc, I think they don't contribute much. > > Geez, even SCO Xenix tar got this right. Dump can't miss it and cpio gets > > it right (even on devs!); so who's tar broke this? (Minix doesn't count 8{) > Recursive cp? (The intuitive, simple, *man page recommended* way to copy > a directory from one hard disk to another?) Good point, though I'd never noticed the recommendation, I've always used: (cd /here && tar cf - .) | ( cd /there && tar xvf - ) I don't know if it is as efficient, but it works well for everything but devs on about everything I've been on. Just different approaches, I guess. > > > They cause inconsistent semantics, but they are recorded in the inode as > > > the number of links to the file the inode holds information on. Therefor > > > any admin who is worth the money they receive for doing their task will > > > know that if the number of links to a file is greater than one another > > > hard link must exist. Searching the filesystem for another name > > > referring the same inode is then not a really hard thing to do... But it can be time consuming. (esp on laptops w/just root filesystem) > > Uh, I know a lot of admins that I consider 'worth their salt' who don't > > check link counts (or maybe even notice them in an 'ls -l') before > > removing a file. I don't think system upgrade scripts do it either. > > And "checking" still allows for race conditions. Especially when > automated. And I agree that checking should not be necessary. I don't trust it either since a friend showed me how to break some of the race conditions. (Interestingly enough with symlink() on a Tandy 6000) > > > Have a look at ls -l `which vi view ex` and think again about what hard > > > links contribute (then again similar functionality might be constructed > > > using soft-links; but they are much harder to administrate (read: keep > > > under control)) > > > > Symlinks do not prevent the original binary from being unavailable. Please > > remember that files don't really go away until all links are zero and no > > more filedescs are open on them. Hey, if 'the founders' had meant for > > symlinks to be used over hard links, there would have been an 'ls -h' > > flag, right? 8{) > > Symlinks don't prevent the filedesc behavior from happening. They do not > allow for the refcount, but the solution that comes to mind is actually > more intuitive: > > mv vi vi-bin > ln -s vi-bin vi > ln -s vi-bin view > > Now you replace the one vi-bin binary and all of vi is upgraded. And it's > easy to see what files are linked to other files--with hard links it can > be quite hard. I can't easily tell what is symlinked-to, if I understand this. I can do things like 'ls -li' to get the inode number and 'find /fs -inum %d -xdev' to find all the bits. I also like the handy ref counter to cross-check. How do I find what is linked to vi (esp. in various filesys /usr/bin, /usr/sbin, /usr/local/bin, ...)? How do I *know* I have all of them with out a ref count cross-check? I can also typo 'ln -s vi-bim ex' and be confused for a few minutes by the 'ex: No such file or directory' when I can see it, but don't recognize the 'ls -l ex' output as another typo. > I'm just not sure that the consistency issues raised by hard links justify > the meager benefits. Please don't "gore my ox" as meager; It's not polite. 8{) Remember that "Meager benefits" is a *very* relative term. As I said before, I did a lot of work on systems without symlinks. Took some getting used-to and resulted in a few extra files (like /bin/rmail was a copy of sendmail), but wasn't too bad. The designers there thought symlinks were of meager benefit. They also thought that more than 64K inodes per filesystem was of meager benefit. 8{( Really, FreeBSD seems to provide every benefit we both feel we need. > > > Just my 0.02 euro. > > > > This means it's euro-pinion? What's the conversion rate? - Jy@ > > Damned if I know, and I'm English. (Of course, I'm English but living in > the US :-). But clearly a European point is far better.. or something. Better than an English or American one? 8{) Or something... - Jy@ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Mar 14 20:16:28 1999 Delivered-To: freebsd-security@freebsd.org Received: from host07.rwsystems.net (kasie.rwsystems.net [209.197.192.103]) by hub.freebsd.org (Postfix) with ESMTP id 0A8CB14EB7 for ; Sun, 14 Mar 1999 20:16:23 -0800 (PST) (envelope-from jwyatt@RWSystems.net) Received: from kasie.rwsystems.net([209.197.192.103]) (3440 bytes) by host07.rwsystems.net via sendmail with P:esmtp/R:bind_hosts/T:inet_zone_bind_smtp (sender: ) id for ; Sun, 14 Mar 1999 21:58:23 -0600 (CST) (Smail-3.2.0.104 1998-Nov-20 #1 built 1998-Dec-24) Date: Sun, 14 Mar 1999 21:58:23 -0600 (CST) From: James Wyatt To: Robert Watson Cc: Jon Hamilton , Peter Jeremy , freebsd-security@FreeBSD.ORG Subject: Re: ACL's In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 14 Mar 1999, Robert Watson wrote: > point of view of the user. Symlinks have consistent behavior across the > entire namespace, and leaving aside the garbage collection issue, provide > pretty much all functionality hardlinks do. I think we seriously disagree on 'pretty much'. Maybe on 'consistent'. > This garbage-collection issue is in fact the change that I want: the names > referencing an object should obey the semantics required by the controller > of the original object, not of anyone who is able to read it at any point > in its history. Symlinks allow me to revoke access to an object > trivially, and consistently with the hierarchal directory behavior. And > since files in UNIX convey capabilities, this is actually extremely > important. Anyone who was able to hard link to it, not just read it. 'chmod 0 file' works orthogonally w.r.t. hard and symbolic links. So does 'cp /dev/null' for those rare times you *have* to be sure. Symlinks allow the original file to 1) disappear and 2) 'look' accessable at first glance. > In response to the absolute symlink concern: this is why in my example > (see some email or another) I used only relative symlinks. You'll find > that, given the arbitrary way partitioning occurs, this is the only useful > way to manage hard links also: the user can specify any > directory-separated partioning scheme they choose when they install, and > most of them make sense. Is there a difference between an absolute and relative hard link? > Removing hard links helps us in a number of ways: it allows for a unique > name relative to a partition for a file (great for auditing and TPE); it > allows atomicity and reliability for deletion, along with prevention of > inode hijacking. It provides a more consistent view of the FS to the > average user: symlinks work across partitions, network file systems, etc. > It allows a unique set of permissions to be evaluated for a file, ensuring > that a common set are applied to all users. It allows revocation of file > access to be ensured by the owner. Ref counts are great for auditing as well, but symlinks don't have them. We've had some suprises with symlinks on NFS. As every symlink I've ever seen has 777 permissions, I have to look (maybe several symlinks deep!) for the original file. If I 'chmod 0' any of a hard link, all of them instantly and directly show the modifications. It's ensured as well. > As with all aliasing, symlinks can result in surprises. I argue that they > result in fewer surprises; in particular, fewer security-related > surprises. I'll argue not many fewer, in practice, but I hope we're winding down. 8{) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Mar 14 23:34: 9 1999 Delivered-To: freebsd-security@freebsd.org Received: from Tele.TM.Odessa.UA (Tele.TM.Odessa.UA [195.66.200.100]) by hub.freebsd.org (Postfix) with ESMTP id 730C915096 for ; Sun, 14 Mar 1999 23:33:53 -0800 (PST) (envelope-from arkadia@odessa.net) Organization: S&PE Telematika Received: from transe.tm.odessa.ua (TransE.TM.Odessa.UA [195.66.198.9]) by Tele.TM.Odessa.UA (8.9.1/8.8.5/TM-Mail-2.5) with ESMTP id JAA10495; Mon, 15 Mar 1999 09:33:19 +0200 (EET) Received: from odessa.net (localhost.transe.tm.odessa.ua [192.168.1.1] (may be forged)) by transe.tm.odessa.ua (8.8.8/8.8.7) with ESMTP id JAA01175; Mon, 15 Mar 1999 09:34:09 +0200 (EET) (envelope-from arkadia@odessa.net) Message-ID: <36ECB7EF.A7C2C969@odessa.net> Date: Mon, 15 Mar 1999 09:34:07 +0200 From: Dmitry Mishchenko X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 2.2.7-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Fernando Schapachnik Cc: freebsd-security@FreeBSD.ORG Subject: Re: WinVirus scannig on a FreeBSD FW References: <199903121246.JAA22979@ns1.sminter.com.ar> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Fernando Schapachnik wrote: > Hello: > I'd like to set up a firewall in which I can scan for PC viruses. > Does anybody know if there's such a tool for FreeBSD? > > TIA! > may be you can use AVP, now it's available for Linux http://www.avp.com and its free for Linux. If someone can run it on FreeBSD please mail me. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Mar 14 23:54:31 1999 Delivered-To: freebsd-security@freebsd.org Received: from haldjas.folklore.ee (Haldjas.folklore.ee [193.40.6.121]) by hub.freebsd.org (Postfix) with ESMTP id BD4EA1522C for ; Sun, 14 Mar 1999 23:54:29 -0800 (PST) (envelope-from narvi@haldjas.folklore.ee) Received: from haldjas.folklore.ee (haldjas.folklore.ee [172.17.2.1] (may be forged)) by haldjas.folklore.ee (8.8.8/8.8.4) with SMTP id JAA04633 for ; Mon, 15 Mar 1999 09:54:10 +0200 (EET) Date: Mon, 15 Mar 1999 09:54:10 +0200 (EET) From: Narvi To: freebsd-security@FreeBSD.ORG Subject: Re: ACL's In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Can any ACL scheme that does not *AUTOMATICALLY* apply the ACL to all hard linked copies of the same file are *FUNDAMENTALLY* broken and IMHO should be kept far away from FreeBSD. The present nonsense about hard vs soft link how to partition or not the hard disk(s) is a clear evidence of the maddness this will lead to. Sander There is no love, no good, no happiness and no future - all these are just illusions. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Mar 15 1:28:51 1999 Delivered-To: freebsd-security@freebsd.org Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id 2AA901528C for ; Mon, 15 Mar 1999 01:28:48 -0800 (PST) (envelope-from peter.jeremy@auss2.alcatel.com.au) Received: by border.alcanet.com.au id <40331>; Mon, 15 Mar 1999 19:16:10 +1000 Date: Mon, 15 Mar 1999 19:28:22 +1000 From: Peter Jeremy Subject: Re: disapointing security architecture To: wes@softweyr.com Cc: freebsd-security@FreeBSD.ORG Message-Id: <99Mar15.191610est.40331@border.alcanet.com.au> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Wes Peters wrote: >Subject: Re: disapointing security architecture >Sender: wes@softweyr.com >To: Peter Jeremy >Cc: >Message-id: <36EBBE93.DEC82C92@softweyr.com> >Organization: Softweyr llc >MIME-version: 1.0 >X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) >Content-transfer-encoding: 7bit >X-Accept-Language: en >References: <99Mar14.193150est.40323@border.alcanet.com.au> >Content-Type: text/plain; charset=us-ascii >Content-Length: 1826 >Status: RO > >Peter Jeremy wrote: >> >> Wes Peters wrote: >> >My suggestion for FreeBSD would be to steal half of the disk direct >> >blocks in the disk inode for ACL information. >you don't have to reserve the space if the file type isn't "file with >ACL." This makes the offset->disk block code messier since NDADDR becomes dependent on di_flags. > you need ACLs on device files too, I thought the block addresses in device files were unused. > and it becomes very expensive to add an ACL to >a file after the fact, Agreed. >> IMHO, stealing an extra inode (or disk block) only for files that need >> ACLs would be preferable (especially if ACL sharing is implemented). > >I agree, but I'm not sure how you would express the ACL sharing idea to >the user. I suspect that in most cases, an ACL will be inherited from a `default ACL' associated with a directory - in which case you just re-use the directory's ACL. I wouldn't expect an exhaustive search - maybe a small cache to catch adding ACLs to a whole bunch of files in one go. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Mar 15 1:46:18 1999 Delivered-To: freebsd-security@freebsd.org Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id DB2B514FA9 for ; Mon, 15 Mar 1999 01:46:01 -0800 (PST) (envelope-from peter.jeremy@auss2.alcatel.com.au) Received: by border.alcanet.com.au id <40331>; Mon, 15 Mar 1999 19:33:24 +1000 Date: Mon, 15 Mar 1999 19:45:37 +1000 From: Peter Jeremy Subject: Re: ACL's To: freebsd-security@FreeBSD.ORG Message-Id: <99Mar15.193324est.40331@border.alcanet.com.au> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org James Wyatt wrote: >Anyone else remember the UseNet wag who said "Symlinks can turn your >filesystem tree into a bramblebush."? Rich Salz, perhaps? - Jy@ There's also `symbolic links: GOTO's for filesystems'. Unfortunately, I don't remember the attribution. patl@phoenix.volant.org wrote: > (It can >detect a lost race condition by opening the file, doing the unlink, >then checking the link count on the open fd before closing.) And if this check fails, what should it do? It can't replace the link. Robert Watson wrote: >The s/owned/writable by/ change suggested sounds reasonable also. I >update my request for broken features and/or security holes given this >change: > >link(thefile, newname) will succeed only if open(thefile, O_RDWR) would >have succeeded, and if open(newname, O_CREAT, 0) would have succeeded. This sounds much better than my suggestion to chmod the file. I can't think of any breakage offhand. Peer To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Mar 15 4:39:26 1999 Delivered-To: freebsd-security@freebsd.org Received: from ns1.sminter.com.ar (ns1.sminter.com.ar [200.10.100.10]) by hub.freebsd.org (Postfix) with ESMTP id CDBAB14D77 for ; Mon, 15 Mar 1999 04:39:22 -0800 (PST) (envelope-from fpscha@ns1.sminter.com.ar) Received: (from fpscha@localhost) by ns1.sminter.com.ar (8.8.5/8.8.4) id JAA28887; Mon, 15 Mar 1999 09:37:33 -0300 (GMT) From: Fernando Schapachnik Message-Id: <199903151237.JAA28887@ns1.sminter.com.ar> Subject: Re: ACL's In-Reply-To: from Robert Watson at "Mar 14, 99 12:24:43 pm" To: robert+freebsd@cyrus.watson.org Date: Mon, 15 Mar 1999 09:37:33 -0300 (GMT) Cc: peter.jeremy@auss2.alcatel.com.au, freebsd-security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL40 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org En un mensaje anterior, Robert Watson escribió: [...] > I think hard links are neat, et al, but I really don't think they add any > new useful functionality above symlinks, and they can certainly introduce > new problems. They save a little disk space here and there (as long as > you don't recursive move anything)... Let me tell you a situation where there is a clear performance loose when using soft links. Heavy used Solaris mail server. /var/mail softlinked to /export/mail (lot of space there). Having around 7000+ users, support calls about "mail retreival is slow" started to appear. Solution: Compile POP3d to use /export/mail directly. Everyone happy again. Regards. Fernando P. Schapachnik Administracion de la red VIA Net Works Argentina SA To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Mar 15 4:47:28 1999 Delivered-To: freebsd-security@freebsd.org Received: from ns1.sminter.com.ar (ns1.sminter.com.ar [200.10.100.10]) by hub.freebsd.org (Postfix) with ESMTP id 2CF73154C3 for ; Mon, 15 Mar 1999 04:47:25 -0800 (PST) (envelope-from fpscha@ns1.sminter.com.ar) Received: (from fpscha@localhost) by ns1.sminter.com.ar (8.8.5/8.8.4) id JAA01091; Mon, 15 Mar 1999 09:41:29 -0300 (GMT) From: Fernando Schapachnik Message-Id: <199903151241.JAA01091@ns1.sminter.com.ar> Subject: Re: ACLs In-Reply-To: <199903140826.AAA89058@apollo.backplane.com> from Matthew Dillon at "Mar 14, 99 00:26:45 am" To: dillon@apollo.backplane.com (Matthew Dillon) Date: Mon, 15 Mar 1999 09:41:29 -0300 (GMT) Cc: dscheidt@enteract.com, unicorn@blackhats.org, freebsd-security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL40 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org En un mensaje anterior, Matthew Dillon escribió: [...] > If you have your machine partitioned correctly, you do not generally > have to worry about hardlinks to system binaries ( suid or otherwise ) > as users do not have access to partitions containing them. This leads me to a question: Why not set the default (auto) file system layout to something like: / /usr /var /home /tmp This not only restrict linking problems, but also allows to specify things like noexec and nosuid on /home and /tmp at least. Regards. Fernando P. Schapachnik Administracion de la red VIA Net Works Argentina SA To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Mar 15 9: 8:46 1999 Delivered-To: freebsd-security@freebsd.org Received: from gatekeeper.iserver.com (gatekeeper.iserver.com [192.41.0.2]) by hub.freebsd.org (Postfix) with ESMTP id AE7D015046 for ; Mon, 15 Mar 1999 09:08:44 -0800 (PST) (envelope-from hart@iserver.com) Received: by gatekeeper.iserver.com; Mon, 15 Mar 1999 10:08:25 -0700 (MST) Received: from unknown(192.168.1.109) by gatekeeper.iserver.com via smap (V3.1.1) id xma010836; Mon, 15 Mar 99 10:08:12 -0700 Received: (hart@localhost) by anchovy.orem.iserver.com (8.9.2) id KAA07554; Mon, 15 Mar 1999 10:08:16 -0700 (MST) Date: Mon, 15 Mar 1999 10:08:16 -0700 (MST) From: Paul Hart X-Sender: hart@anchovy.orem.iserver.com Reply-To: Paul Hart To: David Scheidt Cc: freebsd-security@FreeBSD.ORG Subject: Re: ACLs In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 14 Mar 1999, David Scheidt wrote: > You have to remeber to check, though. I don't look at the link count every > time before I a rm a file. There are all sorts of people admining boxes who > haven't sense to check for this. I suspect there are lots of otherwise > competent people who don't even know to look for this. Removing the problem > might be a better solution than trying to educate the world about it. But that assumes that hard links are always a problem in the first place, which is just not true. Is it really too hard to do a chmod 0 on a SUID binary before removing it? No useful race conditions, no possibility of privilege hijacking through keeping a covert link to the binary that I can see. As was mentioned about these types of admins, "holding their hand by duct-taping foam rubber over a couple of sharp edges isn't doing them any favors at all." I will concede that I am a UNIX purist. Discussion of removing a very useful and long-standing ability of UNIX just because novice admins might not understand it doesn't fly with me. It's kind of like someone saying "oh, using file modes to mark programs as executable is too hard to understand for UNIX novices -- let's make it so that every executable in FreeBSD has to have a filename that ends in '.exe' and that way we can do away with the execute bits in file modes." Would I be the only person that found idea that horribly repulsive? > Programs which do different things depending on the name they are invoked > under is not a feature. I've always thought this was kind of clever, myself. Paul Hart -- Paul Robert Hart ><8> ><8> ><8> Verio Web Hosting, Inc. hart@iserver.com ><8> ><8> ><8> http://www.iserver.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Mar 15 9:38: 3 1999 Delivered-To: freebsd-security@freebsd.org Received: from rembrandt.esys.ca (rembrandt.esys.ca [198.161.92.131]) by hub.freebsd.org (Postfix) with ESMTP id 9589D14DF4 for ; Mon, 15 Mar 1999 09:37:58 -0800 (PST) (envelope-from lyndon@execmail.ca) Received: from execmail.ca (zappa.esys.ca [198.161.92.28]) by rembrandt.esys.ca (2.1/8.9.1/Execmail 2.1) with ESMTP id KAA23858; Mon, 15 Mar 1999 10:37:18 -0700 Message-Id: <199903151737.KAA23858@rembrandt.esys.ca> Date: Mon, 15 Mar 1999 10:37:15 -0700 From: Lyndon Nerenberg Subject: Re: ACL's To: robert+freebsd@cyrus.watson.org Cc: freebsd-security@FreeBSD.ORG In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I think hard links are neat, et al, but I really don't think they add any > new useful functionality above symlinks, and they can certainly introduce > new problems. They save a little disk space here and there (as long as > you don't recursive move anything)... I beg to differ. Our mailstore product uses hard links extensively to reduce disk usage when a message is delivered to multiple recipients. In a corporate environment where someone mails a 50MB MIME message to 100 recipients, the ability to hardlink 99 of those copies makes a *big* difference. Hard links are a very powerful tool that can trip you up if used incorrectly. Just like most things in UNIX can be misused. --lyndon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Mar 15 9:58: 3 1999 Delivered-To: freebsd-security@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id C2F7214CD4 for ; Mon, 15 Mar 1999 09:57:52 -0800 (PST) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 2.12 #1) id 10MbZR-0000B8-00; Mon, 15 Mar 1999 19:54:33 +0200 From: Sheldon Hearn To: Fernando Schapachnik Cc: dillon@apollo.backplane.com (Matthew Dillon), dscheidt@enteract.com, unicorn@blackhats.org, freebsd-security@FreeBSD.ORG Subject: Re: ACLs In-reply-to: Your message of "Mon, 15 Mar 1999 09:41:29 -0300." <199903151241.JAA01091@ns1.sminter.com.ar> Date: Mon, 15 Mar 1999 19:54:33 +0200 Message-ID: <689.921520473@axl.noc.iafrica.com> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 15 Mar 1999 09:41:29 -0300, Fernando Schapachnik wrote: > Why not set the default (auto) file system layout to something like: > > / > /usr > /var > /home > /tmp Because it's impossible to guess at reasonable sizes for /tmp and /home. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Mar 15 10: 6:22 1999 Delivered-To: freebsd-security@freebsd.org Received: from fledge.watson.org (FLEDGE.RES.CMU.EDU [128.2.93.229]) by hub.freebsd.org (Postfix) with ESMTP id 767E214FEC for ; Mon, 15 Mar 1999 10:06:20 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id NAA11504; Mon, 15 Mar 1999 13:05:53 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Mon, 15 Mar 1999 13:05:53 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Narvi Cc: freebsd-security@FreeBSD.ORG Subject: Re: ACL's In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 15 Mar 1999, Narvi wrote: > Can any ACL scheme that does not *AUTOMATICALLY* apply the ACL to all hard > linked copies of the same file are *FUNDAMENTALLY* broken and IMHO should > be kept far away from FreeBSD. I think we all agree that permissions are properties of file system objects (that is, data pointed to by an inode); ACLs would act as an extension to permissions, and as such also be on a per-inode basis. The ACL behavior being discussed by Peter, et al, has to do with reducing space consumption and improving performance in a real-world implementation, and without breaking these semantics. One example of an optimization was to allow multiple objects to share the same ACL storage, and then use a COW-style approach to reduce storage requirements. The assumption was that most files will not have ACLs attached to them, which seems quite fair to me. Presumably this is all optimization that a little bit of profiling would point to once it's actually implemented. > The present nonsense about hard vs soft link how to partition or not the > hard disk(s) is a clear evidence of the maddness this will lead to. I'm not sure I understand how they are related, other than that inconsistent behavior tends to lead to more mistakes on the part of the user :-). I personally believe that requiring bizarre partitioning to protect users from one-another and the system from the users is not a solution to the hard-link problem; that removing a system setuid binary owned by root/bin should have the KISS expected behavior. Others point out that hard links allow for a performance improvement for some applications due to the use of file system names as database names in a database application, and that it has historically been available, resulting in applications that depend on its availability. The compromise that may be emerging is that both points are valid, and reflect the extremeness of both keeping hard links, or completely discarding them. Wilfredo Sanchez's suggestion concerning limiting the ability to create hard links sounds like a promising middle ground that no one has managed to find a problem with yet, and appears to address the concerns of all involved. I flesh out the semantics a little in Pine.BSF.3.96.990314201139.5121L-100000@fledge.watson.org Is there anyone out there using hard links for database applications (such as mail stores, news stores, etc) who would find their programs broken by this change? Robert N Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: 03 01 DD 8E 15 67 48 73 25 6D 10 FC EC 68 C1 1C Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ Safeport Network Services http://www.safeport.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Mar 15 10:57: 4 1999 Delivered-To: freebsd-security@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id A0D9714E87 for ; Mon, 15 Mar 1999 10:56:09 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA01689; Mon, 15 Mar 1999 10:55:38 -0800 (PST) (envelope-from dillon) Date: Mon, 15 Mar 1999 10:55:38 -0800 (PST) From: Matthew Dillon Message-Id: <199903151855.KAA01689@apollo.backplane.com> To: Fernando Schapachnik Cc: robert+freebsd@cyrus.watson.org, peter.jeremy@auss2.alcatel.com.au, freebsd-security@FreeBSD.ORG Subject: Re: ACL's References: <199903151237.JAA28887@ns1.sminter.com.ar> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org : :Let me tell you a situation where there is a clear performance loose when :using soft links. : :Heavy used Solaris mail server. /var/mail softlinked to /export/mail (lot :of space there). :Having around 7000+ users, support calls about "mail retreival is slow" :started to appear. :Solution: Compile POP3d to use /export/mail directly. Everyone happy again. : :Regards. : :Fernando P. Schapachnik :Administracion de la red This is due to the way solaris's namei() caching works. It shouldn't be as big an issue under FreeBSD. Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Mar 15 16:57:20 1999 Delivered-To: freebsd-security@freebsd.org Received: from relay.acadiau.ca (relay.acadiau.ca [131.162.2.90]) by hub.freebsd.org (Postfix) with ESMTP id 3C5451515F for ; Mon, 15 Mar 1999 16:57:03 -0800 (PST) (envelope-from 026809r@dragon.acadiau.ca) Received: from dragon.acadiau.ca (dragon.acadiau.ca [131.162.1.79]) by relay.acadiau.ca (8.8.5/8.8.5) with ESMTP id UAA11938; Mon, 15 Mar 1999 20:56:07 -0400 (AST) Received: from localhost (026809r@localhost) by dragon.acadiau.ca (8.8.8+Sun/8.8.8) with ESMTP id UAA12254; Mon, 15 Mar 1999 20:56:04 -0400 (AST) Date: Mon, 15 Mar 1999 20:56:03 -0400 (AST) From: Michael Richards <026809r@dragon.acadiau.ca> X-Sender: 026809r@dragon To: Sheldon Hearn Cc: Fernando Schapachnik , Matthew Dillon , dscheidt@enteract.com, unicorn@blackhats.org, freebsd-security@FreeBSD.ORG Subject: Partition Sites [was Re: ACLs] In-Reply-To: <689.921520473@axl.noc.iafrica.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 15 Mar 1999, Sheldon Hearn wrote: > > Why not set the default (auto) file system layout to something like: > > > > / > > /usr > > /var > > /home > > /tmp > > Because it's impossible to guess at reasonable sizes for /tmp and /home. Fine. How about asking the user to choose the following things from a list that the machine will be used for and coming up with a reasonable scheme based on that? -Michael To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Mar 15 17: 9:59 1999 Delivered-To: freebsd-security@freebsd.org Received: from freed.libdns.qc.ca (derby.JSP.UMontreal.CA [132.204.45.26]) by hub.freebsd.org (Postfix) with ESMTP id 84B7D150F5 for ; Mon, 15 Mar 1999 17:09:45 -0800 (PST) (envelope-from spidey@libdns.qc.ca) Received: from localhost (spidey@localhost) by freed.libdns.qc.ca (8.9.2/8.9.2) with SMTP id UAA32178; Mon, 15 Mar 1999 20:04:13 -0500 (EST) (envelope-from spidey@libdns.qc.ca) X-Authentication-Warning: freed.libdns.qc.ca: spidey owned process doing -bs Date: Mon, 15 Mar 1999 20:04:13 -0500 (EST) From: Spidey Reply-To: Spidey To: Michael Richards <026809r@dragon.acadiau.ca> Cc: Sheldon Hearn , Fernando Schapachnik , Matthew Dillon , dscheidt@enteract.com, unicorn@blackhats.org, freebsd-security@FreeBSD.ORG Subject: Re: Partition Sites [was Re: ACLs] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org And while we're at it... Why not a nice GUI to resize the partitions? :)) On Mon, 15 Mar 1999, Michael Richards wrote: > On Mon, 15 Mar 1999, Sheldon Hearn wrote: > > > > Why not set the default (auto) file system layout to something like: > > > > > > / > > > /usr > > > /var > > > /home > > > /tmp > > > > Because it's impossible to guess at reasonable sizes for /tmp and /home. > Fine. How about asking the user to choose the following things from a list > that the machine will be used for and coming up with a reasonable scheme > based on that? > > -Michael > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > When a man lies he murders some part of the world These are the pale deaths which men miscall their lives All this I can witness any longer Cannot the kingdom of salvation take me home To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Mar 15 17:18:31 1999 Delivered-To: freebsd-security@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id 3222214DCE for ; Mon, 15 Mar 1999 17:18:23 -0800 (PST) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 2.12 #1) id 10MiQF-0008AL-00; Tue, 16 Mar 1999 03:13:31 +0200 From: Sheldon Hearn To: Spidey Cc: Michael Richards <026809r@dragon.acadiau.ca>, Fernando Schapachnik , Matthew Dillon , dscheidt@enteract.com, unicorn@blackhats.org, freebsd-security@FreeBSD.ORG Subject: Re: Partition Sites [was Re: ACLs] In-reply-to: Your message of "Mon, 15 Mar 1999 20:04:13 EST." Date: Tue, 16 Mar 1999 03:13:30 +0200 Message-ID: <31391.921546810@axl.noc.iafrica.com> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 15 Mar 1999 20:04:13 EST, Spidey wrote: > And while we're at it... Why not a nice GUI to resize the partitions? :)) Go ahead and do it. One of three things will happen: 1) You'll run into problems while you're trying to design the GUI, and you'll realize why it hasn't been done. 2) You'll find that very few people use your GUI, because "off the shelf defaults" for partition sizes are a lame concept. 3) You'll find that lots of people use it and you'll be a hero. Meanwhile, the rest of us will carry on working on the things we can realistically tackle, given our skills and time resources. Good luck, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Mar 15 17:22:44 1999 Delivered-To: freebsd-security@freebsd.org Received: from ns1.sminter.com.ar (ns1.sminter.com.ar [200.10.100.10]) by hub.freebsd.org (Postfix) with ESMTP id 28DB3152EC for ; Mon, 15 Mar 1999 17:22:13 -0800 (PST) (envelope-from fpscha@ns1.sminter.com.ar) Received: (from fpscha@localhost) by ns1.sminter.com.ar (8.8.5/8.8.4) id WAA07534; Mon, 15 Mar 1999 22:09:19 -0300 (GMT) From: Fernando Schapachnik Message-Id: <199903160109.WAA07534@ns1.sminter.com.ar> Subject: Re: Partition Sites [was Re: ACLs] In-Reply-To: from Michael Richards at "Mar 15, 99 08:56:03 pm" To: 026809r@dragon.acadiau.ca (Michael Richards) Date: Mon, 15 Mar 1999 22:09:19 -0300 (GMT) Cc: sheldonh@iafrica.com, dillon@apollo.backplane.com, dscheidt@enteract.com, unicorn@blackhats.org, freebsd-security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL40 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org En un mensaje anterior, Michael Richards escribió: > On Mon, 15 Mar 1999, Sheldon Hearn wrote: > > > > Why not set the default (auto) file system layout to something like: > > > > > > / > > > /usr > > > /var > > > /home > > > /tmp > > > > Because it's impossible to guess at reasonable sizes for /tmp and /home. > Fine. How about asking the user to choose the following things from a list > that the machine will be used for and coming up with a reasonable scheme > based on that? That's a nice idea. You can even use this schemas to suggest a number for MAXUSERS and other related kernel stuff. This can be placed in GENERIC.diff or something similar. Fernando P. Schapachnik Administracion de la red VIA Net Works Argentina SA To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Mar 15 17:23:22 1999 Delivered-To: freebsd-security@freebsd.org Received: from freed.libdns.qc.ca (derby.JSP.UMontreal.CA [132.204.45.26]) by hub.freebsd.org (Postfix) with ESMTP id 119641507C for ; Mon, 15 Mar 1999 17:23:18 -0800 (PST) (envelope-from spidey@libdns.qc.ca) Received: from localhost (spidey@localhost) by freed.libdns.qc.ca (8.9.2/8.9.2) with SMTP id UAA32946; Mon, 15 Mar 1999 20:18:53 -0500 (EST) (envelope-from spidey@libdns.qc.ca) X-Authentication-Warning: freed.libdns.qc.ca: spidey owned process doing -bs Date: Mon, 15 Mar 1999 20:18:52 -0500 (EST) From: Spidey Reply-To: Spidey To: Sheldon Hearn Cc: Michael Richards <026809r@dragon.acadiau.ca>, Fernando Schapachnik , Matthew Dillon , dscheidt@enteract.com, unicorn@blackhats.org, freebsd-security@FreeBSD.ORG Subject: Re: Partition Sites [was Re: ACLs] In-Reply-To: <31391.921546810@axl.noc.iafrica.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org It was a joke, and I'll never carry on such a job... I'd rather attack to monstrous task of resizing existing filesystems!!! Thing which I would obviously not be able to accomplish... :) On Tue, 16 Mar 1999, Sheldon Hearn wrote: > > > On Mon, 15 Mar 1999 20:04:13 EST, Spidey wrote: > > > And while we're at it... Why not a nice GUI to resize the partitions? :)) > > Go ahead and do it. One of three things will happen: > > 1) You'll run into problems while you're trying to design the GUI, and > you'll realize why it hasn't been done. > > 2) You'll find that very few people use your GUI, because "off the shelf > defaults" for partition sizes are a lame concept. > > 3) You'll find that lots of people use it and you'll be a hero. > > Meanwhile, the rest of us will carry on working on the things we can > realistically tackle, given our skills and time resources. > > Good luck, > Sheldon. > When a man lies he murders some part of the world These are the pale deaths which men miscall their lives All this I can witness any longer Cannot the kingdom of salvation take me home To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Mar 15 20:17:33 1999 Delivered-To: freebsd-security@freebsd.org Received: from aniwa.sky (p44-max12.wlg.ihug.co.nz [216.100.145.44]) by hub.freebsd.org (Postfix) with ESMTP id 7A182150C9 for ; Mon, 15 Mar 1999 20:17:21 -0800 (PST) (envelope-from andrew@squiz.co.nz) Received: from aniwa.sky (localhost [127.0.0.1]) by aniwa.sky (8.9.1a/8.9.1) with ESMTP id RAA00717; Tue, 16 Mar 1999 17:11:07 +1300 (NZDT) Message-Id: <199903160411.RAA00717@aniwa.sky> X-Mailer: exmh version 2.0.2 2/24/98 To: Spidey Cc: Sheldon Hearn , Michael Richards <026809r@dragon.acadiau.ca>, Fernando Schapachnik , Matthew Dillon , dscheidt@enteract.com, unicorn@blackhats.org, freebsd-security@FreeBSD.ORG Subject: Re: Partition Sites [was Re: ACLs] In-reply-to: Your message of "Mon, 15 Mar 1999 20:18:52 CDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 16 Mar 1999 17:11:07 +1300 From: Andrew McNaughton Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > It was a joke, and I'll never carry on such a job... I'd rather attack to > monstrous task of resizing existing filesystems!!! Thing which I would > obviously not be able to accomplish... :) I've a pretty limited understanding of the workings of the FreeBSD file system. From that perspective it seems as though the problem mightn't be complex, but the debugging of any work on it would be very painful. Probably I'm wrong and it is complex. I'm curious enough to be interested in improving my understanding of how the filesystem works. Is there any documentation of the layout of the file system available online, or would I have to delve into the source to get more information. Andrew McNaughton ... memories of repairing Apple II floppy file systems by hand using low level disk editing utilities typed in from magazines ... -- ----------- Andrew McNaughton andrew@squiz.co.nz http://www.newsroom.co.nz/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Mar 15 23:28:33 1999 Delivered-To: freebsd-security@freebsd.org Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (Postfix) with ESMTP id 0B01515077 for ; Mon, 15 Mar 1999 23:28:28 -0800 (PST) (envelope-from roberto@keltia.freenix.fr) Received: (from uucp@localhost) by frmug.org (8.9.1/frmug-2.3/nospam) with UUCP id IAA13365 for freebsd-security@FreeBSD.ORG; Tue, 16 Mar 1999 08:28:08 +0100 (CET) (envelope-from roberto@keltia.freenix.fr) Received: by keltia.freenix.fr (Postfix, from userid 101) id 82E4F8848; Tue, 16 Mar 1999 08:25:50 +0100 (CET) Date: Tue, 16 Mar 1999 08:25:50 +0100 From: Ollivier Robert To: freebsd-security@FreeBSD.ORG Subject: Re: Partition Sites [was Re: ACLs] Message-ID: <19990316082550.A11568@keltia.freenix.fr> Mail-Followup-To: freebsd-security@FreeBSD.ORG References: <199903160411.RAA00717@aniwa.sky> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.95.3i In-Reply-To: <199903160411.RAA00717@aniwa.sky>; from Andrew McNaughton on Tue, Mar 16, 1999 at 05:11:07PM +1300 X-Operating-System: FreeBSD 4.0-CURRENT/ELF ctm#5130 AMD-K6 MMX @ 200 MHz Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org According to Andrew McNaughton: > I'm curious enough to be interested in improving my understanding of how > the filesystem works. Is there any documentation of the layout of the > file system available online, or would I have to delve into the source to > get more information. You can look at the paper from McKusick in /usr/share/doc/smm/05.fastfs. PS: your lines are far too long, please cut 'em at around 72 characters. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 4.0-CURRENT #70: Sat Feb 27 09:43:08 CET 1999 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Mar 15 23:48:55 1999 Delivered-To: freebsd-security@freebsd.org Received: from verdi.nethelp.no (verdi.nethelp.no [158.36.41.162]) by hub.freebsd.org (Postfix) with SMTP id C94EB14E44 for ; Mon, 15 Mar 1999 23:48:51 -0800 (PST) (envelope-from sthaug@nethelp.no) Received: (qmail 4157 invoked by uid 1001); 16 Mar 1999 07:48:32 +0000 (GMT) To: beaupran@jsp.umontreal.ca, spidey@libdns.qc.ca Cc: sheldonh@iafrica.com, 026809r@dragon.acadiau.ca, fpscha@ns1.sminter.com.ar, dillon@apollo.backplane.com, dscheidt@enteract.com, unicorn@blackhats.org, freebsd-security@FreeBSD.ORG Subject: Re: Partition Sites [was Re: ACLs] From: sthaug@nethelp.no In-Reply-To: Your message of "Mon, 15 Mar 1999 20:18:52 -0500 (EST)" References: X-Mailer: Mew version 1.05+ on Emacs 19.34.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Tue, 16 Mar 1999 08:48:32 +0100 Message-ID: <4155.921570512@verdi.nethelp.no> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > It was a joke, and I'll never carry on such a job... I'd rather attack to > monstrous task of resizing existing filesystems!!! Thing which I would > obviously not be able to accomplish... :) There is already a program available that can do most of the job, see http://www.nethelp.no/scsi/fsresize.c (No I didn't write it.) It gets the cylinder group summary information wrong, and this has to be fixed by an fsck. I wouldn't feel comfortable using such a system until it got *everything* right... Steinar Haug, Nethelp consulting, sthaug@nethelp.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Mar 16 1:26:44 1999 Delivered-To: freebsd-security@freebsd.org Received: from unix.ir.is (unix.ir.is [194.144.192.5]) by hub.freebsd.org (Postfix) with ESMTP id 23D3A14EEE for ; Tue, 16 Mar 1999 01:26:32 -0800 (PST) (envelope-from cookie@unix.ir.is) Received: (from cookie@localhost) by unix.ir.is (8.9.0/8.9.0) id JAA15969 for freebsd-security@freebsd.org; Tue, 16 Mar 1999 09:20:35 GMT Date: Tue, 16 Mar 1999 09:20:35 GMT From: Kjartan Baldursson Message-Id: <199903160920.JAA15969@unix.ir.is> To: freebsd-security@freebsd.org Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org auth 1e3b2470 unsubscribe cookie@unix.ir.is To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Mar 16 1:49: 3 1999 Delivered-To: freebsd-security@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id B8F36151BA for ; Tue, 16 Mar 1999 01:48:52 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id KAA01802; Tue, 16 Mar 1999 10:48:28 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id KAA03424; Tue, 16 Mar 1999 10:48:28 +0100 (MET) Date: Tue, 16 Mar 1999 10:48:28 +0100 From: Eivind Eklund To: sthaug@nethelp.no Cc: beaupran@jsp.umontreal.ca, spidey@libdns.qc.ca, sheldonh@iafrica.com, 026809r@dragon.acadiau.ca, fpscha@ns1.sminter.com.ar, dillon@apollo.backplane.com, dscheidt@enteract.com, unicorn@blackhats.org, freebsd-security@FreeBSD.ORG Subject: Re: Partition Sites [was Re: ACLs] Message-ID: <19990316104827.C3196@bitbox.follo.net> References: <4155.921570512@verdi.nethelp.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <4155.921570512@verdi.nethelp.no>; from sthaug@nethelp.no on Tue, Mar 16, 1999 at 08:48:32AM +0100 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Mar 16, 1999 at 08:48:32AM +0100, sthaug@nethelp.no wrote: > > It was a joke, and I'll never carry on such a job... I'd rather attack to > > monstrous task of resizing existing filesystems!!! Thing which I would > > obviously not be able to accomplish... :) > > There is already a program available that can do most of the job, see > > http://www.nethelp.no/scsi/fsresize.c > > (No I didn't write it.) It gets the cylinder group summary information > wrong, and this has to be fixed by an fsck. I wouldn't feel comfortable > using such a system until it got *everything* right... According to the author (der Mouse), there are more things it gets wrong. As far as I understood, he doesn't distribute it except to people that want it as a basis for further hacking, as it sometimes eats filesystems. Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Mar 16 1:54:28 1999 Delivered-To: freebsd-security@freebsd.org Received: from nova.kki.krakow.pl (nova.kki.krakow.pl [195.116.9.2]) by hub.freebsd.org (Postfix) with ESMTP id 29EF01517F for ; Tue, 16 Mar 1999 01:53:27 -0800 (PST) (envelope-from shadow@kki.pl) Received: from altair (shadow@altair.kki.krakow.pl [195.116.9.172]) by nova.kki.krakow.pl (8.8.7/Ver.2c) with SMTP id KAA26888 for ; Tue, 16 Mar 1999 10:30:41 +0100 Reply-To: From: "=?iso-8859-2?Q?Robert_'Shadow'_Paj=B1k?=" To: Subject: Strange behaviour ... Date: Tue, 16 Mar 1999 10:32:28 +0100 Message-ID: <000601be6f8f$e8c9d360$ac0974c3@altair.kki.krakow.pl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hey! Maybe some noticed similiar behaviour ... We're running FBSD 3.0-RELEASE at our free server (over 80 thousands of ppl from Poland has e-mail and www pages on it). Few days ago we started to notice some strange behaviour - system was saing: Date, timestamp www /kernel: swap_pager: suggest more swap space: 254 MB But swap space is about 750 of MB! What is more interesting, that all this actions are being made at night! (3 a.m local time). What's more interesting that swap is on new SCSI drive - when badsectors should not exist, and even if they would be there they should be skipped by SCSI hardware. So, has anyone spotted sth similliar ? Or can system do any maintain tasks at night which are not regarded in CronTab ? TIA, Shadow -- Robert Paj±k (shadow@kki.pl) KKI Administrator/Security Officer To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Mar 16 2:34:43 1999 Delivered-To: freebsd-security@freebsd.org Received: from volodya.prime.net.ua (volodya.prime.net.ua [195.64.229.17]) by hub.freebsd.org (Postfix) with ESMTP id A6D19151A4 for ; Tue, 16 Mar 1999 02:34:23 -0800 (PST) (envelope-from andyo@prime.net.ua) Received: from prime.net.ua (localhost.prime.net.ua [127.0.0.1]) by volodya.prime.net.ua (8.8.8/8.8.8) with ESMTP id MAA00442; Tue, 16 Mar 1999 12:39:03 +0200 (EET) (envelope-from andyo@prime.net.ua) Message-ID: <36EE34C4.BC482821@prime.net.ua> Date: Tue, 16 Mar 1999 12:39:01 +0200 From: "Andy V. Oleynik" Organization: M-Info X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 2.2.7-RELEASE i386) X-Accept-Language: ru, uk, en MIME-Version: 1.0 To: shadow@kki.pl Cc: freebsd-security@FreeBSD.ORG Subject: Re: Strange behaviour ... References: <000601be6f8f$e8c9d360$ac0974c3@altair.kki.krakow.pl> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org And what swapinfo says? Robert 'Shadow' Paj±k wrote: > Hey! > > Maybe some noticed similiar behaviour ... We're running FBSD 3.0-RELEASE at > our free server (over 80 thousands of ppl from Poland has e-mail and www > pages on it). > Few days ago we started to notice some strange behaviour - system was saing: > > Date, timestamp www /kernel: swap_pager: suggest more swap space: 254 MB > > But swap space is about 750 of MB! What is more interesting, that all this > actions > are being made at night! (3 a.m local time). What's more interesting that > swap is on new SCSI drive - when badsectors should not exist, and even if > they would be there they should be skipped by SCSI hardware. > > So, has anyone spotted sth similliar ? Or can system do any maintain tasks > at night which are not regarded in CronTab ? > > TIA, Shadow > > -- > Robert Paj±k (shadow@kki.pl) > KKI Administrator/Security Officer > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message -- WBW Andy V. Oleynik (safety sex apologet - no sex at all ö%-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Mar 16 2:52: 4 1999 Delivered-To: freebsd-security@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 55CE915167 for ; Tue, 16 Mar 1999 02:51:54 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id LAA03037; Tue, 16 Mar 1999 11:51:33 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id LAA03729; Tue, 16 Mar 1999 11:51:24 +0100 (MET) Date: Tue, 16 Mar 1999 11:51:23 +0100 From: Eivind Eklund To: "Robert 'Shadow' Paj?k" Cc: freebsd-security@FreeBSD.ORG Subject: Re: Strange behaviour ... Message-ID: <19990316115123.E3196@bitbox.follo.net> References: <000601be6f8f$e8c9d360$ac0974c3@altair.kki.krakow.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <000601be6f8f$e8c9d360$ac0974c3@altair.kki.krakow.pl>; from Robert 'Shadow' Paj?k on Tue, Mar 16, 1999 at 10:32:28AM +0100 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Mar 16, 1999 at 10:32:28AM +0100, Robert 'Shadow' Paj?k wrote: > Hey! > > Maybe some noticed similiar behaviour ... We're running FBSD 3.0-RELEASE at > our free server (over 80 thousands of ppl from Poland has e-mail and www > pages on it). > Few days ago we started to notice some strange behaviour - system was saing: > > Date, timestamp www /kernel: swap_pager: suggest more swap space: 254 MB > > But swap space is about 750 of MB! What is more interesting, that all this > actions > are being made at night! (3 a.m local time). What's more interesting that > swap is on new SCSI drive - when badsectors should not exist, and even if > they would be there they should be skipped by SCSI hardware. > > So, has anyone spotted sth similliar ? Or can system do any maintain tasks > at night which are not regarded in CronTab ? I'm not quite certain what you're trying to say here, but it is common for some of the night jobs to take quite a bit of memory. Are you certain you don't have a user that runs this through his crontab or similar? Info from top or ps might also prove interesting. Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Mar 16 3:53:44 1999 Delivered-To: freebsd-security@freebsd.org Received: from helios.man.lublin.pl (helios.man.lublin.pl [194.92.17.34]) by hub.freebsd.org (Postfix) with ESMTP id 7EC3614D1E for ; Tue, 16 Mar 1999 03:53:37 -0800 (PST) (envelope-from sopel@nemezis.ipan.lublin.pl) Received: from nemezis.ipan.lublin.pl ([193.59.19.154]:3707 "EHLO nemezis.ipan.lublin.pl" ident: "sopel") by helios.man.lublin.pl with ESMTP id <7250-832>; Tue, 16 Mar 1999 12:53:10 +0100 Date: Tue, 16 Mar 1999 12:52:44 +0000 (GMT) From: Wojtek To: =?iso-8859-2?Q?Robert_'Shadow'_Paj=B1k?= Cc: freebsd-security@FreeBSD.ORG Subject: Re: Strange behaviour ... In-Reply-To: <000601be6f8f$e8c9d360$ac0974c3@altair.kki.krakow.pl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org i advise you to switch to 3.1 as soon as You can. afaik strange things happen on 3.0 release... very strange... greetings, sopel To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Mar 16 4: 0:16 1999 Delivered-To: freebsd-security@freebsd.org Received: from nova.kki.krakow.pl (nova.kki.krakow.pl [195.116.9.2]) by hub.freebsd.org (Postfix) with ESMTP id 3B27115141; Tue, 16 Mar 1999 03:56:34 -0800 (PST) (envelope-from shadow@kki.pl) Received: from altair (shadow@altair.kki.krakow.pl [195.116.9.172]) by nova.kki.krakow.pl (8.8.7/Ver.2c) with SMTP id MAA03019; Tue, 16 Mar 1999 12:36:48 +0100 Reply-To: From: "=?iso-8859-1?Q?Robert_'Shadow'_Paj=B9k?=" To: "Eivind Eklund" Cc: Subject: RE: Strange behaviour ... Date: Tue, 16 Mar 1999 12:38:26 +0100 Message-ID: <001701be6fa1$819fbda0$ac0974c3@altair.kki.krakow.pl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <19990316115123.E3196@bitbox.follo.net> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I'm not quite certain what you're trying to say here, but it is common > for some of the night jobs to take quite a bit of memory. That we're in trouble :-) > Are you certain you don't have a user that runs this through his > crontab or similar? Info from top or ps might also prove interesting. Nope, users are excluded - no user has shell. I think it is coused by periodic -options... Still investigating. Sorry for bothering you. It just happened to suddenly. Thanks. And sorry if it is false alarm. -- Robert Pajak (shadow@kki.pl) KKI Administrator/Security Officer To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Mar 16 4: 0:39 1999 Delivered-To: freebsd-security@freebsd.org Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (Postfix) with ESMTP id 52DB9151D2 for ; Tue, 16 Mar 1999 03:59:05 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191]) by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id DAA25676; Tue, 16 Mar 1999 03:57:07 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id DAA10967; Tue, 16 Mar 1999 03:57:06 -0800 (PST) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id DAA25889; Tue, 16 Mar 1999 03:57:04 -0800 (PST) From: Don Lewis Message-Id: <199903161157.DAA25889@salsa.gv.tsc.tdk.com> Date: Tue, 16 Mar 1999 03:57:04 -0800 In-Reply-To: Robert Watson "Re: ACL's" (Mar 14, 2:07pm) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: Robert Watson , James Wyatt Subject: Re: ACL's Cc: The Unicorn , Thomas Valentino Crimi , freebsd-security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mar 14, 2:07pm, Robert Watson wrote: } Subject: Re: ACL's } On Sun, 14 Mar 1999, James Wyatt wrote: } > Geez, even SCO Xenix tar got this right. Dump can't miss it and cpio gets } > it right (even on devs!); so who's tar broke this? (Minix doesn't count 8{) } } Recursive cp? (The intuitive, simple, *man page recommended* way to copy } a directory from one hard disk to another?) GNU cp with the "-a" option does the right thing. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Mar 16 4:30:35 1999 Delivered-To: freebsd-security@freebsd.org Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (Postfix) with ESMTP id 0F95A14F6E for ; Tue, 16 Mar 1999 04:30:31 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191]) by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id EAA25838; Tue, 16 Mar 1999 04:30:01 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id EAA11040; Tue, 16 Mar 1999 04:30:00 -0800 (PST) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id EAA25944; Tue, 16 Mar 1999 04:29:59 -0800 (PST) From: Don Lewis Message-Id: <199903161229.EAA25944@salsa.gv.tsc.tdk.com> Date: Tue, 16 Mar 1999 04:29:59 -0800 In-Reply-To: Jared Mauch "Re: ACL's" (Mar 14, 4:35pm) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: Jared Mauch , Wilfredo Sanchez Subject: Re: ACL's Cc: Robert Watson , Thomas Valentino Crimi , freebsd-security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mar 14, 4:35pm, Jared Mauch wrote: } Subject: Re: ACL's } On Sun, Mar 14, 1999 at 01:28:52PM -0800, Wilfredo Sanchez wrote: } > Is there any reason (other than "it always has been so") why users } > should be allowed to create hard links to files they don't own? } } I personally can't think of one. } } What would be interesting would be to see a kernel option } for it, have some folks test it, and see what might break } from this going on. I'd prefer a mount option, which would allow this policy to be configured on a per-filesystem basis. If you found that you needed this capability, you might be able to limit it to one little filesystem. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Mar 16 4:37:14 1999 Delivered-To: freebsd-security@freebsd.org Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (Postfix) with ESMTP id AC6DC14FFC for ; Tue, 16 Mar 1999 04:37:09 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191]) by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id EAA25868; Tue, 16 Mar 1999 04:36:46 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id EAA11058; Tue, 16 Mar 1999 04:36:45 -0800 (PST) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id EAA25960; Tue, 16 Mar 1999 04:36:44 -0800 (PST) From: Don Lewis Message-Id: <199903161236.EAA25960@salsa.gv.tsc.tdk.com> Date: Tue, 16 Mar 1999 04:36:44 -0800 In-Reply-To: Robert Watson "Re: ACL's" (Mar 14, 6:02pm) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: Robert Watson , Wilfredo Sanchez Subject: Re: ACL's Cc: Thomas Valentino Crimi , freebsd-security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mar 14, 6:02pm, Robert Watson wrote: } Subject: Re: ACL's } On Sun, 14 Mar 1999, Wilfredo Sanchez wrote: } > Is there any reason (other than "it always has been so") why users } > should be allowed to create hard links to files they don't own? } } This variation on the restriction theme seems quite promising. Off hand, } I don't know of any linking behavior in the base system that relies on } renaming files owned by other users (except rename, and that is a separate } syscall). Most of the database applications people are mentioning } (including news) probably remain within the scope of a single user, I } would guess? And a number of the attacks of interest are related to } setuid or other files owned by different users (specifically interesting } ones). It seems to address well my concern that users cannot revoke access } to a file. Now they can be sure that rename() or chmod() followed by } revoke() to address data files, and simply unlink to dispose of a setuid } file. Setuid is presumably only of interest on open() so continued access } to an already instantied setuid session is probably fine. } } Rename could be induced to look like a hard link by causing a system } crash/power failure at an appropriate point in the rename procedure, I } would guess. But that's probably not in the scope of the security } protections we're addressing at this point. :-) Rename would only be a concern in cases where one of the links to the file in question was located in a directory that was writeable by the user attempting to do the rename. I suspect that most users won't install their setuid executables in directories that someone else has write permission on. Plain files might also be of concern (in directories like /tmp), but in most cases the directory will have the sticky bit, preventing rename from working. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Mar 16 4:43:19 1999 Delivered-To: freebsd-security@freebsd.org Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (Postfix) with ESMTP id C249C151E3 for ; Tue, 16 Mar 1999 04:43:00 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191]) by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id EAA25895; Tue, 16 Mar 1999 04:42:36 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id EAA11070; Tue, 16 Mar 1999 04:42:34 -0800 (PST) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id EAA26010; Tue, 16 Mar 1999 04:42:34 -0800 (PST) From: Don Lewis Message-Id: <199903161242.EAA26010@salsa.gv.tsc.tdk.com> Date: Tue, 16 Mar 1999 04:42:33 -0800 In-Reply-To: Robert Watson "Re: ACL's" (Mar 14, 12:24pm) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: Robert Watson , Peter Jeremy Subject: Re: ACL's Cc: freebsd-security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mar 14, 12:24pm, Robert Watson wrote: } Subject: Re: ACL's } I think hard links are neat, et al, but I really don't think they add any } new useful functionality above symlinks, and they can certainly introduce } new problems. They save a little disk space here and there (as long as } you don't recursive move anything)... I've seen hard links used to implement a simple locking scheme that can be used by shell scripts. The first place I encountered this was C News. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Mar 16 7:46:21 1999 Delivered-To: freebsd-security@freebsd.org Received: from host07.rwsystems.net (kasie.rwsystems.net [209.197.192.103]) by hub.freebsd.org (Postfix) with ESMTP id D1C2715272 for ; Tue, 16 Mar 1999 07:46:18 -0800 (PST) (envelope-from jwyatt@RWSystems.net) Received: from kasie.rwsystems.net([209.197.192.103]) (2316 bytes) by host07.rwsystems.net via sendmail with P:esmtp/R:bind_hosts/T:inet_zone_bind_smtp (sender: ) id for ; Tue, 16 Mar 1999 09:38:01 -0600 (CST) (Smail-3.2.0.104 1998-Nov-20 #1 built 1998-Dec-24) Date: Tue, 16 Mar 1999 09:37:59 -0600 (CST) From: James Wyatt To: =?iso-8859-2?Q?Robert_'Shadow'_Paj=B1k?= Cc: freebsd-security@FreeBSD.ORG Subject: Re: Strange behaviour ... In-Reply-To: <000601be6f8f$e8c9d360$ac0974c3@altair.kki.krakow.pl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: 8BIT Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 16 Mar 1999, [iso-8859-2] Robert 'Shadow' Paj±k wrote: > Maybe some noticed similiar behaviour ... We're running FBSD 3.0-RELEASE at > our free server (over 80 thousands of ppl from Poland has e-mail and www > pages on it). > Few days ago we started to notice some strange behaviour - system was saing: > > Date, timestamp www /kernel: swap_pager: suggest more swap space: 254 MB > > But swap space is about 750 of MB! What is more interesting, that all this > actions > are being made at night! (3 a.m local time). What's more interesting that > swap is on new SCSI drive - when badsectors should not exist, and even if > they would be there they should be skipped by SCSI hardware. I have had the 'daily' entry in /etc/crontab do something like this when I had zillions of files on a couple of largeish RAID filesystems. I had missed putting the directories in the /etc/locate.rc PRUNEPATHS line and it ran *way* out of sort room at about 03:00 or so. (Thanks again kward!) Have you checked /var/log/messages or dmesg for exceptions? The swapinfo command tells the normal swap setup at runtime. btw: If you want to find any commands related to 'something', just do an 'apropos [something]', like 'apropos swap'. It helps quite a bit if you are an infrequent sysadmin or cover several flavors of Unix. I would also recommend upgrading to 3.1-RELEASE as soon as possible. I do not know it's the problem, but 3.0-* had some issues. 3.0-* didn't go on anything but test/thrash machines here, though it worked fine there. We consider anything ending in '.0' as ready for final test. 8{) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Mar 16 8: 6: 9 1999 Delivered-To: freebsd-security@freebsd.org Received: from freed.libdns.qc.ca (derby.JSP.UMontreal.CA [132.204.45.26]) by hub.freebsd.org (Postfix) with ESMTP id 367AA151E8 for ; Tue, 16 Mar 1999 08:05:52 -0800 (PST) (envelope-from spidey@libdns.qc.ca) Received: from localhost (spidey@localhost) by freed.libdns.qc.ca (8.9.2/8.9.2) with SMTP id BAA49789; Tue, 16 Mar 1999 01:59:05 -0500 (EST) (envelope-from spidey@libdns.qc.ca) X-Authentication-Warning: freed.libdns.qc.ca: spidey owned process doing -bs Date: Tue, 16 Mar 1999 01:59:05 -0500 (EST) From: Spidey Reply-To: Spidey To: Andrew McNaughton Cc: Sheldon Hearn , Michael Richards <026809r@dragon.acadiau.ca>, Fernando Schapachnik , Matthew Dillon , dscheidt@enteract.com, unicorn@blackhats.org, freebsd-security@FreeBSD.ORG Subject: Re: Partition Sites [was Re: ACLs] In-Reply-To: <199903160411.RAA00717@aniwa.sky> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 16 Mar 1999, Andrew McNaughton wrote: > > It was a joke, and I'll never carry on such a job... I'd rather attack to > > monstrous task of resizing existing filesystems!!! Thing which I would > > obviously not be able to accomplish... :) > > I've a pretty limited understanding of the workings of the FreeBSD file > system. Neither do I.. > From that perspective it seems as though the problem mightn't > be complex, but the debugging of any work on it would be very painful. > Probably I'm wrong and it is complex. I think this is very intricate matter! Sure as hell it would be a nightmare to debug, and I _won't_ try the beta on my HD!!! :) (This should go to -hackers mailing list...) > I'm curious enough to be interested in improving my understanding of how > the filesystem works. Is there any documentation of the layout of the > file system available online, or would I have to delve into the source > to get more information. I really don't know about this, and I'm extremely curious about it myself! I made some weird manipulations on my drive like growing my FBSD slice over the Win95 one... and melting 2 BSD partitions into one, but most of the time, this required newfs'ing some data in the making (= make backups, which I don't have) Anyways, I don't think that starting the 'source code quest' could be very useful to me.. knowing not even where to start... When a man lies he murders some part of the world These are the pale deaths which men miscall their lives All this I can witness any longer Cannot the kingdom of salvation take me home To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Mar 16 14:39:13 1999 Delivered-To: freebsd-security@freebsd.org Received: from beatrice.rutgers.edu (beatrice.rutgers.edu [165.230.209.226]) by hub.freebsd.org (Postfix) with ESMTP id 99F2D1551B for ; Tue, 16 Mar 1999 14:38:39 -0800 (PST) (envelope-from easmith@beatrice.rutgers.edu) Received: (from easmith@localhost) by beatrice.rutgers.edu (980427.SGI.8.8.8/970903.SGI.AUTOCF) id RAA11541; Tue, 16 Mar 1999 17:06:10 -0500 (EST) From: "Allen Smith" Message-Id: <9903161706.ZM11539@beatrice.rutgers.edu> Date: Tue, 16 Mar 1999 17:06:09 -0500 In-Reply-To: Robert Watson "Re: ACL's" (Mar 14, 8:04pm) References: X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Robert Watson Subject: Re: ACL's Cc: freebsd-security@FreeBSD.ORG Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mar 14, 8:04pm, Robert Watson (possibly) wrote: > The s/owned/writable by/ change suggested sounds reasonable also. I > update my request for broken features and/or security holes given this > change: > > link(thefile, newname) will succeed only if open(thefile, O_RDWR) would > have succeeded, and if open(newname, O_CREAT, 0) would have succeeded. > > In this manner, the following interesting behavior is restricted: > > a) Joe user may not hard link a setuid root binary mode 755 from /usr/sbin > to /usr/home/joeuser/privatebin, as they could not have opened the binary > for writing. > > b) Joe user may not hard link another users data file mode 644 in > /usr/home/samuser/patentapplication to /usr/home/joeuser/privatedata as > they could not have opened the data file for writing. > > The following behavior is not restricted: > > c) Joe user may hard link a data file they own in their home directory to > another name. > > d) Joe user may hard link a group-writable file in another user's home if > Joe user is in the group of the file. > > e) Root may hard link any file to any other file on the same partition. > > Through the addition of file system ACLs, this is really quite flexible. > > So we are still in search of any other real-world use that might be broken > as a result of the change. Might I suggest that an intermediary between "hard links unlimited" (the current case) and "hard links only if you can write the file" could be gotten by forbidding hardlinks to suid/sgid binaries, unless the user was: A. root; B. the user the suid was to; or C. a member of the group the sgid was to? This appears to minimize the risk of breakage. Normally, you'd be worried about a race between a supposed stat and the link, but since this would be a system call this isn't a worry except for multiprocessor systems (the vnode would need to be locked from the start of the stat to the end of the link). -Allen -- Allen Smith easmith@beatrice.rutgers.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Mar 17 3:43:10 1999 Delivered-To: freebsd-security@freebsd.org Received: from xkis.kis.ru (xkis.kis.ru [195.98.32.200]) by hub.freebsd.org (Postfix) with ESMTP id 2279815274; Wed, 17 Mar 1999 03:43:05 -0800 (PST) (envelope-from dv@dv.ru) Received: from localhost (dv@localhost) by xkis.kis.ru (8.9.0/8.9.0) with SMTP id OAA16894; Wed, 17 Mar 1999 14:42:46 +0300 (MSK) Date: Wed, 17 Mar 1999 14:42:46 +0300 (MSK) From: Dmitry Valdov X-Sender: dv@xkis.kis.ru To: freebsd-current@freebsd.org, freebsd-security@freebsd.org Subject: disk quota overriding Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi! There is a way to overflow / filesystem even is quota is enabled. Just make many hard links (for example /bin/sh) to /tmp/ for ($q=0;$q<100000;$q++){ system ("ln /bin/sh /tmp/ln$q"); } Because /tmp directory usually owned by root that why quotas has no effect. *Directory* size of /tmp can be grown up to available space on / filesystem. Any way to fix it? Dmitry. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Mar 17 3:50:21 1999 Delivered-To: freebsd-security@freebsd.org Received: from bofh.fastnet.co.uk (lart.org.uk [194.207.104.22]) by hub.freebsd.org (Postfix) with ESMTP id 47C171500B; Wed, 17 Mar 1999 03:50:02 -0800 (PST) (envelope-from netadmin@bofh.fastnet.co.uk) Received: (from netadmin@localhost) by bofh.fastnet.co.uk (8.8.8/8.8.8) id LAA23132; Wed, 17 Mar 1999 11:49:33 GMT (envelope-from netadmin) Date: Wed, 17 Mar 1999 11:49:32 +0000 From: Jay Tribick To: Dmitry Valdov Cc: freebsd-current@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: disk quota overriding Message-ID: <19990317114932.Z21466@bofh.fastnet.co.uk> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: ; "Dmitry Valdov" on 17.03.1999 @ 11:42:46 GMT Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi > There is a way to overflow / filesystem even is quota is enabled. > > Just make many hard links (for example /bin/sh) to /tmp/ > > for ($q=0;$q<100000;$q++){ > system ("ln /bin/sh /tmp/ln$q"); > } > > Because /tmp directory usually owned by root that why quotas has no effect. > *Directory* size of /tmp can be grown up to available space on / filesystem. > > Any way to fix it? Haven't tested this, but are you sure it fills the filesystem up - all a hard link is, is a file with the same inode as the original file (correct me if I'm wrong) - therefore it doesn't actually use any space other than that required to store the file entry. -- Regards, Jay Tribick [| Network Admin | FastNet International | http://fast.net.uk/ |] [| Finger netadmin@fastnet.co.uk for contact info & PGP PubKey |] [| +44 (0)1273 T: 677633 F: 621631 e: netadmin@fast.net.uk |] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Mar 17 3:51:27 1999 Delivered-To: freebsd-security@freebsd.org Received: from ns1.sminter.com.ar (ns1.sminter.com.ar [200.10.100.10]) by hub.freebsd.org (Postfix) with ESMTP id 3DEAB1506F; Wed, 17 Mar 1999 03:51:23 -0800 (PST) (envelope-from fpscha@ns1.sminter.com.ar) Received: (from fpscha@localhost) by ns1.sminter.com.ar (8.8.5/8.8.4) id IAA23361; Wed, 17 Mar 1999 08:50:50 -0300 (GMT) From: Fernando Schapachnik Message-Id: <199903171150.IAA23361@ns1.sminter.com.ar> Subject: Re: disk quota overriding In-Reply-To: from Dmitry Valdov at "Mar 17, 99 02:42:46 pm" To: dv@dv.ru (Dmitry Valdov) Date: Wed, 17 Mar 1999 08:50:50 -0300 (GMT) Cc: freebsd-current@FreeBSD.ORG, freebsd-security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL40 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Are you aware that, due to nature of hardlinks the only extra space is same that for an empty file? Due to this, how many empty files do you think it takes to eat the whole space of / ? I'm I loosing something? Regards. En un mensaje anterior, Dmitry Valdov escribió: > Hi! > > There is a way to overflow / filesystem even is quota is enabled. > > Just make many hard links (for example /bin/sh) to /tmp/ > > for ($q=0;$q<100000;$q++){ > system ("ln /bin/sh /tmp/ln$q"); > } > > Because /tmp directory usually owned by root that why quotas has no effect. > *Directory* size of /tmp can be grown up to available space on / filesystem. > > Any way to fix it? Fernando P. Schapachnik Administracion de la red VIA Net Works Argentina SA To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Mar 17 3:53:58 1999 Delivered-To: freebsd-security@freebsd.org Received: from xkis.kis.ru (xkis.kis.ru [195.98.32.200]) by hub.freebsd.org (Postfix) with ESMTP id 66B2814CFB; Wed, 17 Mar 1999 03:53:52 -0800 (PST) (envelope-from dv@dv.ru) Received: from localhost (dv@localhost) by xkis.kis.ru (8.9.0/8.9.0) with SMTP id OAA21067; Wed, 17 Mar 1999 14:53:19 +0300 (MSK) Date: Wed, 17 Mar 1999 14:53:19 +0300 (MSK) From: Dmitry Valdov X-Sender: dv@xkis.kis.ru To: Jay Tribick Cc: freebsd-current@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: disk quota overriding In-Reply-To: <19990317114932.Z21466@bofh.fastnet.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 17 Mar 1999, Jay Tribick wrote: > Date: Wed, 17 Mar 1999 11:49:32 +0000 > From: Jay Tribick > To: Dmitry Valdov > Cc: freebsd-current@FreeBSD.ORG, freebsd-security@FreeBSD.ORG > Subject: Re: disk quota overriding > > Hi > > > There is a way to overflow / filesystem even is quota is enabled. > > > > Just make many hard links (for example /bin/sh) to /tmp/ > > > > for ($q=0;$q<100000;$q++){ > > system ("ln /bin/sh /tmp/ln$q"); > > } > > > > Because /tmp directory usually owned by root that why quotas has no effect. > > *Directory* size of /tmp can be grown up to available space on / filesystem. > > > > Any way to fix it? > > Haven't tested this, but are you sure it fills the filesystem up - > all a hard link is, is a file with the same inode as the > original file (correct me if I'm wrong) - therefore it > doesn't actually use any space other than that required > to store the file entry. ^^^^^^^^^^^^^^^^^^^^^ Yes. But /tmp dir is under root filesystem. So *directory* size of /tmp can be grown up to free space on /. Which will result 0 bytes free on / :) All available space will be used to store directory entries. Dmitry. PS. Sorry for my english. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Mar 17 3:56:39 1999 Delivered-To: freebsd-security@freebsd.org Received: from xkis.kis.ru (xkis.kis.ru [195.98.32.200]) by hub.freebsd.org (Postfix) with ESMTP id F259E1535D; Wed, 17 Mar 1999 03:56:34 -0800 (PST) (envelope-from dv@dv.ru) Received: from localhost (dv@localhost) by xkis.kis.ru (8.9.0/8.9.0) with ESMTP id OAA21212; Wed, 17 Mar 1999 14:56:07 +0300 (MSK) Date: Wed, 17 Mar 1999 14:56:07 +0300 (MSK) From: Dmitry Valdov X-Sender: dv@xkis.kis.ru To: Fernando Schapachnik Cc: freebsd-current@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: disk quota overriding In-Reply-To: <199903171150.IAA23361@ns1.sminter.com.ar> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=KOI8-R Content-Transfer-Encoding: 8BIT Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 17 Mar 1999, Fernando Schapachnik wrote: > Date: Wed, 17 Mar 1999 08:50:50 -0300 (GMT) > From: Fernando Schapachnik > To: Dmitry Valdov > Cc: freebsd-current@FreeBSD.ORG, freebsd-security@FreeBSD.ORG > Subject: Re: disk quota overriding > > Are you aware that, due to nature of hardlinks the only extra space is > same that for an empty file? Due to this, how many empty files do you > think it takes to eat the whole space of / ? No. Many empty files can be controlled by INODE QUOTAS. Hard links can't. But I can create as many hard links as I need to eat up the whole space of /... > > I'm I loosing something? > > Regards. > > En un mensaje anterior, Dmitry Valdov escribió: > > Hi! > > > > There is a way to overflow / filesystem even is quota is enabled. > > > > Just make many hard links (for example /bin/sh) to /tmp/ > > > > for ($q=0;$q<100000;$q++){ > > system ("ln /bin/sh /tmp/ln$q"); > > } > > > > Because /tmp directory usually owned by root that why quotas has no effect. > > *Directory* size of /tmp can be grown up to available space on / filesystem. > > > > Any way to fix it? > > > Fernando P. Schapachnik > Administracion de la red > VIA Net Works Argentina SA > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Mar 17 4:37:29 1999 Delivered-To: freebsd-security@freebsd.org Received: from xkis.kis.ru (xkis.kis.ru [195.98.32.200]) by hub.freebsd.org (Postfix) with ESMTP id 135DB15614; Wed, 17 Mar 1999 04:37:23 -0800 (PST) (envelope-from dv@dv.ru) Received: from localhost (dv@localhost) by xkis.kis.ru (8.9.0/8.9.0) with SMTP id PAA05380; Wed, 17 Mar 1999 15:37:03 +0300 (MSK) Date: Wed, 17 Mar 1999 15:37:03 +0300 (MSK) From: Dmitry Valdov X-Sender: dv@xkis.kis.ru To: freebsd-current@freebsd.org, freebsd-security@freebsd.org Subject: Re: disk quota overriding In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi! I think that there is only one way to fix it - it's to disable making *hard*links to directory with mode 1777. On Wed, 17 Mar 1999, Dmitry Valdov wrote: > Date: Wed, 17 Mar 1999 14:42:46 +0300 (MSK) > From: Dmitry Valdov > To: freebsd-current@freebsd.org, freebsd-security@freebsd.org > Subject: disk quota overriding > > Hi! > > There is a way to overflow / filesystem even is quota is enabled. > > Just make many hard links (for example /bin/sh) to /tmp/ > > for ($q=0;$q<100000;$q++){ > system ("ln /bin/sh /tmp/ln$q"); > } > > Because /tmp directory usually owned by root that why quotas has no effect. > *Directory* size of /tmp can be grown up to available space on / filesystem. > > Any way to fix it? > > Dmitry. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Mar 17 5:19:38 1999 Delivered-To: freebsd-security@freebsd.org Received: from gjp.erols.com (alex-va-n008c079.moon.jic.com [206.156.18.89]) by hub.freebsd.org (Postfix) with ESMTP id 6191714D71 for ; Wed, 17 Mar 1999 05:19:35 -0800 (PST) (envelope-from gjp@gjp.erols.com) Received: from gjp.erols.com (localhost.erols.com [127.0.0.1]) by gjp.erols.com (8.9.1/8.8.7) with ESMTP id IAA63439; Wed, 17 Mar 1999 08:16:48 -0500 (EST) (envelope-from gjp@gjp.erols.com) To: Wojtek Cc: "=?iso-8859-2?Q?Robert_'Shadow'_Paj=B1k?=" , freebsd-security@FreeBSD.ORG From: "Gary Palmer" Subject: Re: Strange behaviour ... In-reply-to: Your message of "Tue, 16 Mar 1999 12:52:44 GMT." Date: Wed, 17 Mar 1999 08:16:48 -0500 Message-ID: <63435.921676608@gjp.erols.com> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Wojtek wrote in message ID : > i advise you to switch to 3.1 as soon as You can. > afaik strange things happen on 3.0 release... very strange... We had our first report of abduction of someone running 3.0-RELEASE by a UFO this morning. :) Gary -- Gary Palmer FreeBSD Core Team Member FreeBSD: Turning PC's into workstations. See http://www.FreeBSD.ORG/ for info To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Mar 17 5:40:46 1999 Delivered-To: freebsd-security@freebsd.org Received: from titan.metropolitan.at (unknown [195.212.98.131]) by hub.freebsd.org (Postfix) with ESMTP id C24FD15165; Wed, 17 Mar 1999 05:40:36 -0800 (PST) (envelope-from mladavac@metropolitan.at) Received: by TITAN with Internet Mail Service (5.0.1458.49) id ; Wed, 17 Mar 1999 14:42:39 +0100 Message-ID: <97A8CA5BF490D211A94F0000F6C2E55D097564@s-lmh-wi-900.corpnet.at> From: Ladavac Marino To: 'Dmitry Valdov' , freebsd-current@freebsd.org, freebsd-security@freebsd.org Subject: RE: disk quota overriding Date: Wed, 17 Mar 1999 14:37:32 +0100 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > -----Original Message----- > From: Dmitry Valdov [SMTP:dv@dv.ru] > Sent: Wednesday, March 17, 1999 1:37 PM > To: freebsd-current@freebsd.org; freebsd-security@freebsd.org > Subject: Re: disk quota overriding > > Hi! > > > I think that there is only one way to fix it - it's to disable making > *hard*links to directory with mode 1777. > [ML] But only if the quotas have been turned on. BTW, has chown been "fixed" to the ludicrous SysV semantics that the root and owner can chown a file? If so, the latter has to be disabled in presence of quotas on the volume--otherwise: touch big_file chmod 777 big_file chown root:wheel big_file cat /dev/zero >>big_file This joke used to work on HPUX 10.something which kept the owner-may-chown semantics even in presence of quotas. It was not funny. (I don't know whether HP has fixed that). /Marino To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Mar 17 5:45:50 1999 Delivered-To: freebsd-security@freebsd.org Received: from kot.ne.mediaone.net (kot.ne.mediaone.net [24.218.12.203]) by hub.freebsd.org (Postfix) with ESMTP id 2974215222; Wed, 17 Mar 1999 05:45:47 -0800 (PST) (envelope-from mi@kot.ne.mediaone.net) Received: (from mi@localhost) by kot.ne.mediaone.net (8.9.1a/8.9.1) id IAA21904; Wed, 17 Mar 1999 08:44:12 -0500 (EST) From: Mikhail Teterin Message-Id: <199903171344.IAA21904@kot.ne.mediaone.net> Subject: Re: disk quota overriding In-Reply-To: from Dmitry Valdov at "Mar 17, 1999 03:37:03 pm" To: dv@dv.ru (Dmitry Valdov) Date: Wed, 17 Mar 1999 08:44:11 -0500 (EST) Cc: freebsd-current@FreeBSD.ORG, freebsd-security@FreeBSD.ORG X-Face: %UW#n0|w>ydeGt/b@1-.UFP=K^~-:0f#O:D7w hJ5G_<5143Bb3kOIs9XpX+"V+~$adGP:J|SLieM31VIhqXeLBli" Because /tmp directory usually owned by root that why quotas has no effect. => *Directory* size of /tmp can be grown up to available space on / filesystem. -mi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Mar 17 5:49:43 1999 Delivered-To: freebsd-security@freebsd.org Received: from xkis.kis.ru (xkis.kis.ru [195.98.32.200]) by hub.freebsd.org (Postfix) with ESMTP id 4202F1531C; Wed, 17 Mar 1999 05:49:34 -0800 (PST) (envelope-from dv@dv.ru) Received: from localhost (dv@localhost) by xkis.kis.ru (8.9.0/8.9.0) with SMTP id QAA29170; Wed, 17 Mar 1999 16:47:36 +0300 (MSK) Date: Wed, 17 Mar 1999 16:47:36 +0300 (MSK) From: Dmitry Valdov X-Sender: dv@xkis.kis.ru To: Ladavac Marino Cc: freebsd-current@freebsd.org, freebsd-security@freebsd.org Subject: RE: disk quota overriding In-Reply-To: <97A8CA5BF490D211A94F0000F6C2E55D097564@s-lmh-wi-900.corpnet.at> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 17 Mar 1999, Ladavac Marino wrote: > Date: Wed, 17 Mar 1999 14:37:32 +0100 > From: Ladavac Marino > To: 'Dmitry Valdov' , freebsd-current@freebsd.org, > freebsd-security@freebsd.org > Subject: RE: disk quota overriding > > > -----Original Message----- > > From: Dmitry Valdov [SMTP:dv@dv.ru] > > Sent: Wednesday, March 17, 1999 1:37 PM > > To: freebsd-current@freebsd.org; freebsd-security@freebsd.org > > Subject: Re: disk quota overriding > > > > Hi! > > > > > > I think that there is only one way to fix it - it's to disable making > > *hard*links to directory with mode 1777. > > > [ML] But only if the quotas have been turned on. Sure. What Core Team thinks about it? Dmitry. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Mar 17 6:42:14 1999 Delivered-To: freebsd-security@freebsd.org Received: from woodstock.monkey.net (pern-2-41.mdm.mkt.execpc.com [169.207.89.169]) by hub.freebsd.org (Postfix) with ESMTP id 50BA114BF1; Wed, 17 Mar 1999 06:42:10 -0800 (PST) (envelope-from hamilton@pobox.com) Received: from pobox.com (localhost [127.0.0.1]) by woodstock.monkey.net (Postfix) with ESMTP id 12DFF62; Wed, 17 Mar 1999 08:41:48 -0600 (CST) To: Ladavac Marino Cc: "'Dmitry Valdov'" , freebsd-current@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: disk quota overriding In-reply-to: Your message of "Wed, 17 Mar 1999 14:37:32 +0100." <97A8CA5BF490D211A94F0000F6C2E55D097564@s-lmh-wi-900.corpnet.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 17 Mar 1999 08:41:47 -0600 From: Jon Hamilton Message-Id: <19990317144148.12DFF62@woodstock.monkey.net> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <97A8CA5BF490D211A94F0000F6C2E55D097564@s-lmh-wi-900.corpnet.at>, La davac Marino wrote: } BTW, has chown been "fixed" to the ludicrous SysV semantics that } the root and owner can chown a file? If so, the latter has to be } disabled in presence of quotas on the volume--otherwise: } } touch big_file } chmod 777 big_file } chown root:wheel big_file } cat /dev/zero >>big_file } } This joke used to work on HPUX 10.something which kept the } owner-may-chown semantics even in presence of quotas. It was not funny. } (I don't know whether HP has fixed that). Under HP-UX 9.x, the behavior you describe was the default, and it was changable by altering a kernel config parameter and relinking the kernel. The same tunable is available under 10.x, but I'm less certain what the default behavior is there. Whether quotas are enabled or not does not affect the behavior, only the kernel tunable parameter. -- Jon Hamilton hamilton@pobox.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Mar 17 6:59:44 1999 Delivered-To: freebsd-security@freebsd.org Received: from relay.acadiau.ca (relay.acadiau.ca [131.162.2.90]) by hub.freebsd.org (Postfix) with ESMTP id 89AEC14D71; Wed, 17 Mar 1999 06:59:24 -0800 (PST) (envelope-from 026809r@dragon.acadiau.ca) Received: from dragon.acadiau.ca (dragon.acadiau.ca [131.162.1.79]) by relay.acadiau.ca (8.8.5/8.8.5) with ESMTP id KAA02991; Wed, 17 Mar 1999 10:58:21 -0400 (AST) Received: from localhost (026809r@localhost) by dragon.acadiau.ca (8.8.8+Sun/8.8.8) with ESMTP id KAA11028; Wed, 17 Mar 1999 10:58:16 -0400 (AST) Date: Wed, 17 Mar 1999 10:58:16 -0400 (AST) From: Michael Richards <026809r@dragon.acadiau.ca> X-Sender: 026809r@dragon To: Jon Hamilton Cc: Ladavac Marino , "'Dmitry Valdov'" , freebsd-current@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: disk quota overriding In-Reply-To: <19990317144148.12DFF62@woodstock.monkey.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 17 Mar 1999, Jon Hamilton wrote: > } touch big_file > } chmod 777 big_file > } chown root:wheel big_file > } cat /dev/zero >>big_file > } This joke used to work on HPUX 10.something which kept the > } owner-may-chown semantics even in presence of quotas. It was not funny. > } (I don't know whether HP has fixed that). > > Under HP-UX 9.x, the behavior you describe was the default, and it > was changable by altering a kernel config parameter and relinking the > kernel. The same tunable is available under 10.x, but I'm less certain > what the default behavior is there. Whether quotas are enabled or not > does not affect the behavior, only the kernel tunable parameter. We all know that there are oodles of security problems associated with file giveaways. As I recall, all the texts I have ever read on the subject say that unless there is a very good reason to allow giveaways, they should be disabled. -Michael To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Mar 17 7:20:34 1999 Delivered-To: freebsd-security@freebsd.org Received: from tsolab.org (dnn.rockefeller.edu [129.85.17.127]) by hub.freebsd.org (Postfix) with ESMTP id 8FB7814CA9; Wed, 17 Mar 1999 07:20:32 -0800 (PST) (envelope-from dan@tsolab.org) Received: from tsolab.org (ts011d14.hil-ny.concentric.net [206.173.17.26]) by tsolab.org (8.8.7/8.8.7) with ESMTP id KAA00470; Wed, 17 Mar 1999 10:20:30 -0500 (EST) (envelope-from dan@tsolab.org) Message-ID: <36EFC7F2.860738C4@tsolab.org> Date: Wed, 17 Mar 1999 10:19:14 -0500 From: Dan Tso Reply-To: dan@tsolab.org Organization: The Rockefeller University X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: Dmitry Valdov Cc: freebsd-current@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: disk quota overriding References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Dmitry Valdov wrote: > There is a way to overflow / filesystem even is quota is enabled. > > Just make many hard links (for example /bin/sh) to /tmp/ > > for ($q=0;$q<100000;$q++){ > system ("ln /bin/sh /tmp/ln$q"); > } > > Because /tmp directory usually owned by root that why quotas has no effect. > *Directory* size of /tmp can be grown up to available space on / filesystem. > > Any way to fix it? I've always thought that /tmp should be its own filesystem anyways and I generally make it so. Avoids all sorts of nasties. It seems silly to mix up the most vital system files on the same filesystem as the most volitile, damage-prone directory (/tmp). Its better to newfs /tmp regularly. As far as the other issue, the ability to fill up any public 777 directory even with quotas, perhaps the quota system should look at the 1000 bit and do something special with it. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Mar 17 9:16:33 1999 Delivered-To: freebsd-security@freebsd.org Received: from host07.rwsystems.net (kasie.rwsystems.net [209.197.192.103]) by hub.freebsd.org (Postfix) with ESMTP id D538B15210; Wed, 17 Mar 1999 09:16:29 -0800 (PST) (envelope-from jwyatt@RWSystems.net) Received: from kasie.rwsystems.net([209.197.192.103]) (1771 bytes) by host07.rwsystems.net via sendmail with P:esmtp/R:bind_hosts/T:inet_zone_bind_smtp (sender: ) id for ; Wed, 17 Mar 1999 11:01:12 -0600 (CST) (Smail-3.2.0.104 1998-Nov-20 #1 built 1998-Dec-24) Date: Wed, 17 Mar 1999 11:01:05 -0600 (CST) From: James Wyatt To: Fernando Schapachnik Cc: Dmitry Valdov , freebsd-current@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: disk quota overriding In-Reply-To: <199903171150.IAA23361@ns1.sminter.com.ar> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 17 Mar 1999, Fernando Schapachnik wrote: > Are you aware that, due to nature of hardlinks the only extra space is > same that for an empty file? Due to this, how many empty files do you > think it takes to eat the whole space of / ? They take *less* space than an empty file, just the directory entry. You can see how muchh by looking at the size of the '.' grow when you add one. An empty file still takes an inode, as an 'ls -li [filename]' will show. Now a small amount of anything multiplied by a large number can amount to something. If you have a small root, I can see where you could overwhelm it. It will also take longer and longer to ann the links and lookups in /tmp will take forever. Dmitry Valdov wrote: > > Because /tmp directory usually owned by root that why quotas has no effect. > > *Directory* size of /tmp can be grown up to available space on / filesystem. My favorite way is a /tmp filesystem. It solves stability problems unrelated to quotas as well. Same goes for /home if you have real users on your system (not just a server) - Jy@ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Mar 17 9:16:51 1999 Delivered-To: freebsd-security@freebsd.org Received: from host07.rwsystems.net (kasie.rwsystems.net [209.197.192.103]) by hub.freebsd.org (Postfix) with ESMTP id D470615290; Wed, 17 Mar 1999 09:16:45 -0800 (PST) (envelope-from jwyatt@RWSystems.net) Received: from kasie.rwsystems.net([209.197.192.103]) (1049 bytes) by host07.rwsystems.net via sendmail with P:esmtp/R:bind_hosts/T:inet_zone_bind_smtp (sender: ) id for ; Wed, 17 Mar 1999 11:08:45 -0600 (CST) (Smail-3.2.0.104 1998-Nov-20 #1 built 1998-Dec-24) Date: Wed, 17 Mar 1999 11:08:45 -0600 (CST) From: James Wyatt To: Dmitry Valdov Cc: freebsd-current@freebsd.org, freebsd-security@freebsd.org Subject: Re: disk quota overriding In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 17 Mar 1999, Dmitry Valdov wrote: > I think that there is only one way to fix it - it's to disable making > *hard*links to directory with mode 1777. I'm wondering: are you concerned this is possible, or that you really have a user doing it? I have kicked users off the system for less when they have trounced the machine for others. This is beginning to sound like more of the hard/symlink eruptions last week... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Mar 17 10:16:58 1999 Delivered-To: freebsd-security@freebsd.org Received: from mta2-rme.xtra.co.nz (mta.xtra.co.nz [203.96.92.3]) by hub.freebsd.org (Postfix) with ESMTP id 91168152AA; Wed, 17 Mar 1999 10:16:55 -0800 (PST) (envelope-from junkmale@pop3.xtra.co.nz) Received: from wocker ([210.55.164.76]) by mta2-rme.xtra.co.nz (InterMail v04.00.02.07 201-227-108) with SMTP id <19990317181804.PAWH3226200.mta2-rme@wocker>; Thu, 18 Mar 1999 07:18:04 +1300 From: "Dan Langille" Organization: The FreeBSD Diary To: "Gary Palmer" Date: Thu, 18 Mar 1999 07:16:35 +1300 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Strange behaviour ... Reply-To: junkmale@xtra.co.nz Cc: freebsd-security@FreeBSD.ORG References: Your message of "Tue, 16 Mar 1999 12:52:44 GMT." In-reply-to: <63435.921676608@gjp.erols.com> X-mailer: Pegasus Mail for Win32 (v3.01d) Message-Id: <19990317181804.PAWH3226200.mta2-rme@wocker> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 17 Mar 99, at 8:16, Gary Palmer wrote: > Wojtek wrote in message ID > : > > i advise you to switch to 3.1 as soon as You can. > > afaik strange things happen on 3.0 release... very strange... > > We had our first report of abduction of someone running 3.0-RELEASE by > a UFO this morning. Yes, but how many went unreported? -- Dan Langille The FreeBSD Diary http://www.FreeBSDDiary.com/freebsd To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Mar 17 10:21:30 1999 Delivered-To: freebsd-security@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id D4F0815398; Wed, 17 Mar 1999 10:21:26 -0800 (PST) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id DAA28439; Thu, 18 Mar 1999 03:21:12 +0900 (JST) Message-ID: <36EFEE5A.DE68FF5F@newsguy.com> Date: Thu, 18 Mar 1999 03:03:06 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: Dmitry Valdov Cc: freebsd-current@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: disk quota overriding References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Dmitry Valdov wrote: > > Hi! > > I think that there is only one way to fix it - it's to disable making > *hard*links to directory with mode 1777. *IF* you are using quotas. Otherwise, it could break things for people. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "What happened?" "It moved, sir!" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Mar 17 10:21:39 1999 Delivered-To: freebsd-security@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id A39B8153A6; Wed, 17 Mar 1999 10:21:35 -0800 (PST) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id DAA28431; Thu, 18 Mar 1999 03:21:04 +0900 (JST) Message-ID: <36EFEDEC.D11C7599@newsguy.com> Date: Thu, 18 Mar 1999 03:01:16 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: Jay Tribick Cc: Dmitry Valdov , freebsd-current@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: disk quota overriding References: <19990317114932.Z21466@bofh.fastnet.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Jay Tribick wrote: > > > There is a way to overflow / filesystem even is quota is enabled. > > > > Just make many hard links (for example /bin/sh) to /tmp/ > > > > for ($q=0;$q<100000;$q++){ > > system ("ln /bin/sh /tmp/ln$q"); > > } > > > > Because /tmp directory usually owned by root that why quotas has no effect. > > *Directory* size of /tmp can be grown up to available space on / filesystem. > > > > Any way to fix it? > > Haven't tested this, but are you sure it fills the filesystem up - > all a hard link is, is a file with the same inode as the > original file (correct me if I'm wrong) - therefore it > doesn't actually use any space other than that required > to store the file entry. You missed the dirty trick... :-) It's the size of +/tmp+ that fills /. The *directory* size. Because it has to *store* all these links... -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "What happened?" "It moved, sir!" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Mar 17 12:15:41 1999 Delivered-To: freebsd-security@freebsd.org Received: from ns1.seidata.com (ns1.seidata.com [208.10.211.2]) by hub.freebsd.org (Postfix) with ESMTP id 2E925152B7; Wed, 17 Mar 1999 12:15:37 -0800 (PST) (envelope-from mike@seidata.com) Received: from localhost (mike@localhost) by ns1.seidata.com (8.8.8/8.8.5) with ESMTP id PAA06127; Wed, 17 Mar 1999 15:15:11 -0500 (EST) Date: Wed, 17 Mar 1999 15:15:10 -0500 (EST) From: To: Ladavac Marino Cc: "'Dmitry Valdov'" , freebsd-current@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: RE: disk quota overriding In-Reply-To: <97A8CA5BF490D211A94F0000F6C2E55D097564@s-lmh-wi-900.corpnet.at> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 17 Mar 1999, Ladavac Marino wrote: > chown root:wheel big_file AFAIK, only root can 'give ownership away' on most modern Unix'. Later, -Mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Mar 17 13:28:19 1999 Delivered-To: freebsd-security@freebsd.org Received: from marlin.corp.gulf.net (marlin.corp.gulf.net [198.69.72.17]) by hub.freebsd.org (Postfix) with ESMTP id D662815460 for ; Wed, 17 Mar 1999 13:28:17 -0800 (PST) (envelope-from scott@marlin.corp.gulf.net) Received: from localhost (scott@localhost) by marlin.corp.gulf.net (8.9.1a/8.9.1) with SMTP id PAA05735 for ; Wed, 17 Mar 1999 15:27:40 -0600 (CST) Date: Wed, 17 Mar 1999 15:27:39 -0600 (CST) From: Scott Madley To: freebsd-security@freebsd.org Subject: unsubscribe Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org unsubscribe _____ | ___| Scott Madley | |___ ____ ____ _______ ______ Gulf Coast Internet Company |___ | __| |__ __|_ __| http://www.gulf.net ___| | |__| | | | | | | scott@corp.gulf.net |_____|____|____| |_| |_| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Mar 17 15: 1:23 1999 Delivered-To: freebsd-security@freebsd.org Received: from smtp.enteract.com (thor.enteract.com [207.229.143.11]) by hub.freebsd.org (Postfix) with SMTP id E0CA8152E4 for ; Wed, 17 Mar 1999 15:01:20 -0800 (PST) (envelope-from dscheidt@enteract.com) Received: (qmail 3696 invoked from network); 17 Mar 1999 23:01:00 -0000 Received: from nathan.enteract.com (dscheidt@207.229.143.6) by thor.enteract.com with SMTP; 17 Mar 1999 23:01:00 -0000 Date: Wed, 17 Mar 1999 17:01:00 -0600 (CST) From: David Scheidt To: Jon Hamilton Cc: Ladavac Marino , 'Dmitry Valdov' , freebsd-current@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: disk quota overriding In-Reply-To: <19990317144148.12DFF62@woodstock.monkey.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 17 Mar 1999, Jon Hamilton wrote: :Under HP-UX 9.x, the behavior you describe was the default, and it :was changable by altering a kernel config parameter and relinking the :kernel. The same tunable is available under 10.x, but I'm less certain :what the default behavior is there. Whether quotas are enabled or not :does not affect the behavior, only the kernel tunable parameter. This is still the default in 10.20. At least, all of the machines around here are that way. It has some uses on test and lab type machines, as it makes some tasks not have to involve root. As default behavior for a production machine, it is damn silly. David Scheidt : To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Mar 17 17: 1:38 1999 Delivered-To: freebsd-security@freebsd.org Received: from aurora.galaxia.com (trantor.galaxia.com [209.213.94.97]) by hub.freebsd.org (Postfix) with ESMTP id D20C9152A6; Wed, 17 Mar 1999 17:01:33 -0800 (PST) (envelope-from dave@galaxia.com) Received: from localhost (dave@localhost) by aurora.galaxia.com (8.8.8/8.8.7) with ESMTP id UAA11484; Wed, 17 Mar 1999 20:00:17 -0500 (EST) (envelope-from dave@galaxia.com) Date: Wed, 17 Mar 1999 20:00:17 -0500 (EST) From: "David H. Brierley" To: James Wyatt Cc: Fernando Schapachnik , Dmitry Valdov , freebsd-current@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: disk quota overriding In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 17 Mar 1999, James Wyatt wrote: > Now a small amount of anything multiplied by a large number can amount to > something. If you have a small root, I can see where you could overwhelm > it. It will also take longer and longer to ann the links and lookups in > /tmp will take forever. On any machine which allows general users to log in, I strongly recommend making separate file systems for /, /usr, /tmp, and /home, plus any other areas you expect to grow large. Keeping / and /usr separate prevents people from playing "ln" tricks to gain root access. Keeping /tmp separate helps prevent /tmp from breaking your system when it fills up (note that I say "when" and not "if"). Keeping the users on a separate partition helps keep them under control because you can do things like mount the partition with the "nosuid" attribute. The only time I ever create a machine with a single large partition is when I am creating a dedicated server machine that will only allow logins from trusted staff members. -- David H. Brierley dave@galaxia.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Mar 17 19: 0:51 1999 Delivered-To: freebsd-security@freebsd.org Received: from ppc1.cybertime.ch (ppc1.cybertime.ch [194.191.120.136]) by hub.freebsd.org (Postfix) with ESMTP id 3B69414C99 for ; Wed, 17 Mar 1999 19:00:47 -0800 (PST) (envelope-from pajarola@cybertime.ch) Received: from tiamat.dlc.cybertime.ch (tiamat.dlc.cybertime.ch [194.191.120.143]) by ppc1.cybertime.ch (8.9.2/8.9.2) with SMTP id EAA65572; Thu, 18 Mar 1999 04:00:18 +0100 Message-Id: <3.0.32.19990318034657.00a1f100@shrike.overmind.ch> X-Sender: pajarola@shrike.overmind.ch X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 18 Mar 1999 04:00:28 +0100 To: security@FreeBSD.ORG From: Rico Pajarola Subject: Re: disk quota overriding Cc: Dmitry Valdov Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org That's just another symptom of the hardlink-to-files-you-dont-own problem. It allows you to create files (or at least directory entries for files) you don't own. I'd really like to have a mount-option (or maybe a sysctl) to prevent that behaviour (allow hardlinks only if you could write to the file). I use hardlinks very often, but I never had a case where someone should have been able to hardlink to a file he didn't own AND a symlink wasn't good enough (for whatever reason). I extensively use hardlinks (diskless workstations) so I wouldn't like to see them go completely, but I always thought it was impossible to hardlink to files you can't write to, until I tried it myself after the recent discussion. It allows you to create directory entries for files you couldn't have created yourself, which is somehow strange. I very often have home on /usr, because usually that's the place where all the excess disk space goes (on machines with shell users I always made them a separate partition, thank god, but only because I don't completely trust quotas, and I don't want to give my users even the slightest chance to overflow /usr). On all other partitions, they're not allowed to do anything. Besides, I consider /tmp on / filesystem a bad thing anyway (I like the idea of a ro / filesystem where only root can write to, and also only 'by hand'). If I don't have enough disk space to make it an own partition, I link it to /usr/root-tmp or something like that. Rico >Hi! > >There is a way to overflow / filesystem even is quota is enabled. > >Just make many hard links (for example /bin/sh) to /tmp/ > >for ($q=0;$q<100000;$q++){ >system ("ln /bin/sh /tmp/ln$q"); >} > >Because /tmp directory usually owned by root that why quotas has no effect. >*Directory* size of /tmp can be grown up to available space on / filesystem. > >Any way to fix it? > >Dmitry. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Mar 18 1: 6:34 1999 Delivered-To: freebsd-security@freebsd.org Received: from nova.kki.krakow.pl (nova.kki.krakow.pl [195.116.9.2]) by hub.freebsd.org (Postfix) with ESMTP id 1048114E28 for ; Thu, 18 Mar 1999 01:05:20 -0800 (PST) (envelope-from shadow@kki.pl) Received: from altair (shadow@altair.kki.krakow.pl [195.116.9.172]) by nova.kki.krakow.pl (8.8.7/Ver.2c) with SMTP id KAA14076 for ; Thu, 18 Mar 1999 10:04:14 +0100 Reply-To: From: "=?iso-8859-1?Q?Robert_'Shadow'_Paj=B9k?=" To: Subject: RE: Strange behaviour ... Date: Thu, 18 Mar 1999 10:06:09 +0100 Message-ID: <002201be711e$905ca1e0$ac0974c3@altair.kki.krakow.pl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 In-Reply-To: <19990317181804.PAWH3226200.mta2-rme@wocker> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Whoa, I'm now almost sure that this behaviour is happening becous of daily maintain task on such big system. When we turned off daily (nigtly ;) task(s) machine is still up. Thamnks for all your answers, I will still be watching system, and if sth will change I'll let know. Thanks again. -- Robert Pajak (shadow@kki.pl) KKI Administrator/Security Officer To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Mar 18 4:45:47 1999 Delivered-To: freebsd-security@freebsd.org Received: from aniwa.sky (p40-max5.wlg.ihug.co.nz [202.49.241.40]) by hub.freebsd.org (Postfix) with ESMTP id BCACD151DB; Thu, 18 Mar 1999 04:45:11 -0800 (PST) (envelope-from andrew@squiz.co.nz) Received: from aniwa.sky (localhost [127.0.0.1]) by aniwa.sky (8.9.1a/8.9.1) with ESMTP id BAA22599; Fri, 19 Mar 1999 01:43:40 +1300 (NZDT) Message-Id: <199903181243.BAA22599@aniwa.sky> X-Mailer: exmh version 2.0.2 2/24/98 To: "Daniel C. Sobral" Cc: Dmitry Valdov , freebsd-current@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: disk quota overriding In-reply-to: Your message of "Thu, 18 Mar 1999 03:03:06 +0900." <36EFEE5A.DE68FF5F@newsguy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 19 Mar 1999 01:43:39 +1300 From: Andrew McNaughton Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Dmitry Valdov wrote: > > I think that there is only one way to fix it - it's to disable making > > *hard*links to directory with mode 1777. I don't use quotas, and don't know a great deal about how they operate, but I think there's another disk filling DOS involving hard links lurking which the above measure would also solve. If a user starts making hard links to (large and growing) log files, with the new links being placed in /var/mail, then presumably those log files will not be deleted correctly as they are rolled over, and will quickly accumulate. This could not bring down a system as rapidly as growing the publicly writable directory with lots of links, but it is not desirable system behaviour. Andrew McNaughton -- ----------- Andrew McNaughton andrew@squiz.co.nz http://www.newsroom.co.nz/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Mar 18 5:19:24 1999 Delivered-To: freebsd-security@freebsd.org Received: from metrocon.com (metrocon.com [208.9.142.32]) by hub.freebsd.org (Postfix) with ESMTP id 6230E14DBF for ; Thu, 18 Mar 1999 05:19:14 -0800 (PST) (envelope-from emilm@metrocon.com) Received: from localhost (emilm@localhost) by metrocon.com (8.9.2/8.8.3) with SMTP id IAA62143 for ; Thu, 18 Mar 1999 08:15:40 GMT Date: Thu, 18 Mar 1999 08:15:40 +0000 (GMT) From: Emil Mikhles To: freebsd-security@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, I am running IPFIREWALL/NATD, and am getting continious error messages "/kernel: arp: 192.100.100.117 is on xl1 but got reply from 00:08:c7:9a:17:f9 on xl0" "/kernel: arp: 208.17.78.122 is on lo0 but got reply from 00:10:4b:6e:8a:6b on xl1", etc. What is causing this, and how do I prevent this from happening. Thanks, Emil. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Mar 18 6: 4:33 1999 Delivered-To: freebsd-security@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 57504153ED; Thu, 18 Mar 1999 06:04:30 -0800 (PST) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id XAA06792; Thu, 18 Mar 1999 23:03:32 +0900 (JST) Message-ID: <36F10682.1028368F@newsguy.com> Date: Thu, 18 Mar 1999 22:58:26 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: Andrew McNaughton Cc: Dmitry Valdov , freebsd-current@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: disk quota overriding References: <199903181243.BAA22599@aniwa.sky> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Andrew McNaughton wrote: > > I don't use quotas, and don't know a great deal about how they operate, but I think there's another disk filling DOS involving hard links lurking which the above measure would also solve. > > If a user starts making hard links to (large and growing) log files, with the new links being placed in /var/mail, then presumably those log files will not be deleted correctly as they are rolled over, and will quickly accumulate. And what the f* is the user doing with read access to the log directory? -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "What happened?" "It moved, sir!" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Mar 18 6:25:18 1999 Delivered-To: freebsd-security@freebsd.org Received: from fledge.watson.org (FLEDGE.RES.CMU.EDU [128.2.93.229]) by hub.freebsd.org (Postfix) with ESMTP id 2849D15404; Thu, 18 Mar 1999 06:25:15 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id JAA00307; Thu, 18 Mar 1999 09:23:43 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Thu, 18 Mar 1999 09:23:43 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Andrew McNaughton Cc: "Daniel C. Sobral" , Dmitry Valdov , freebsd-current@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: disk quota overriding In-Reply-To: <199903181243.BAA22599@aniwa.sky> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 19 Mar 1999, Andrew McNaughton wrote: > > Dmitry Valdov wrote: > > > I think that there is only one way to fix it - it's to disable making > > > *hard*links to directory with mode 1777. > > I don't use quotas, and don't know a great deal about how they operate, > but I think there's another disk filling DOS involving hard links > lurking which the above measure would also solve. > > If a user starts making hard links to (large and growing) log files, > with the new links being placed in /var/mail, then presumably those log > files will not be deleted correctly as they are rolled over, and will > quickly accumulate. > > This could not bring down a system as rapidly as growing the publicly > writable directory with lots of links, but it is not desirable system > behaviour. So, yet another risk associated with allowing hard links :-). Again, presumably the answer here is either a) restrict the creation of hard links, and b) make sure that users never have write access to any partition you don't want them to have the ability to preserve files on. The linking behavior in conjunction with quotas makes a lot of sense: if a user wants to consume someone else's quota, she just hard links to their files so they cannot delete them. And if she are mean, she links to them in private directories so the victim cannot find the links. Even if the user truncates the file, the inode is still consumed in their name. Robert N Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: 03 01 DD 8E 15 67 48 73 25 6D 10 FC EC 68 C1 1C Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ Safeport Network Services http://www.safeport.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Mar 18 7: 0:28 1999 Delivered-To: freebsd-security@freebsd.org Received: from mail.hamptons.com (mail.hamptons.com [204.141.112.204]) by hub.freebsd.org (Postfix) with ESMTP id 28F7F14C19 for ; Thu, 18 Mar 1999 07:00:19 -0800 (PST) (envelope-from timothy@hamptons.com) Received: from [204.141.112.245] ([204.141.112.245]) by mail.hamptons.com with ESMTP (IPAD 2.06) id 5017700 ; Thu, 18 Mar 1999 09:44:45 EST Message-Id: In-Reply-To: <36F10682.1028368F@newsguy.com> References: <199903181243.BAA22599@aniwa.sky> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 18 Mar 1999 09:54:31 -0500 To: freebsd-security@freebsd.org From: "Timothy R. Platt" Subject: Re: disk quota overriding Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > >And what the f* is the user doing with read access to the log >directory? > At least wtmp has to be readable.. When I installed 2.2.6 /var/log/messages was also readable by all, by default. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Mar 18 8:16:42 1999 Delivered-To: freebsd-security@freebsd.org Received: from host07.rwsystems.net (kasie.rwsystems.net [209.197.192.103]) by hub.freebsd.org (Postfix) with ESMTP id C5DFA15404; Thu, 18 Mar 1999 08:16:39 -0800 (PST) (envelope-from jwyatt@RWSystems.net) Received: from kasie.rwsystems.net([209.197.192.103]) (1988 bytes) by host07.rwsystems.net via sendmail with P:esmtp/R:bind_hosts/T:inet_zone_bind_smtp (sender: ) id for ; Thu, 18 Mar 1999 10:01:28 -0600 (CST) (Smail-3.2.0.104 1998-Nov-20 #1 built 1998-Dec-24) Date: Thu, 18 Mar 1999 10:01:20 -0600 (CST) From: James Wyatt To: Andrew McNaughton Cc: "Daniel C. Sobral" , Dmitry Valdov , freebsd-current@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: disk quota overriding In-Reply-To: <199903181243.BAA22599@aniwa.sky> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 19 Mar 1999, Andrew McNaughton wrote: > > Dmitry Valdov wrote: > > > I think that there is only one way to fix it - it's to disable making > > > *hard*links to directory with mode 1777. > > I don't use quotas, and don't know a great deal about how they > operate, but I think there's another disk filling DOS involving hard > links lurking which the above measure would also solve. If a user > starts making hard links to (large and growing) log files, with the > new links being placed in /var/mail, then presumably those log files > will not be deleted correctly as they are rolled over, and will > quickly accumulate. > > This could not bring down a system as rapidly as growing the publicly > writable directory with lots of links, but it is not desirable system > behaviour. This is beginning to sound like a broken record: 1) I usually move mail to /var/spool/mail, 2) You can't hard link between /var and /var/spool partitions. On some machines /var/log is a filesys to prevent logfile overflows from filling /var anyway. I usually make a different /var/spool on largish machines to help upgrades go faster. I tend to unmount it, /home, and /usr/local and completely replace the OS. No doubt there are other ways to fix this... - Jy@ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Mar 18 8:36: 9 1999 Delivered-To: freebsd-security@freebsd.org Received: from mail.euroweb.hu (mail.euroweb.hu [193.226.220.4]) by hub.freebsd.org (Postfix) with ESMTP id 548691527B for ; Thu, 18 Mar 1999 08:35:59 -0800 (PST) (envelope-from hu006co@mail.euroweb.hu) Received: (from hu006co@localhost) by mail.euroweb.hu (8.8.5/8.8.5) id RAA18405 for freebsd-security@freebsd.org; Thu, 18 Mar 1999 17:35:38 +0100 (MET) Received: (from zgabor@localhost) by CoDe.hu (8.8.8/8.8.8) id QAA00446 for freebsd-security@freebsd.org; Thu, 18 Mar 1999 16:56:06 +0100 (CET) (envelope-from zgabor) From: Zahemszky Gabor Message-Id: <199903181556.QAA00446@CoDe.hu> Subject: Re: disk quota overriding In-Reply-To: from David Scheidt at "Mar 17, 99 05:01:00 pm" To: freebsd-security@freebsd.org Date: Thu, 18 Mar 1999 16:56:05 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > On Wed, 17 Mar 1999, Jon Hamilton wrote: > > :Under HP-UX 9.x, the behavior you describe was the default, and it > :was changable by altering a kernel config parameter and relinking the > :kernel. The same tunable is available under 10.x, but I'm less certain > :what the default behavior is there. Whether quotas are enabled or not > :does not affect the behavior, only the kernel tunable parameter. > > This is still the default in 10.20. At least, all of the machines around here > are that way. It has some uses on test and lab type machines, as it makes > some tasks not have to involve root. As default behavior for a production > machine, it is damn silly. Hrrr! RTFM! on any HP-UX system, you have to type ``man setprivgrp'', and read ahead about the priviledges. Eg. there is one (I think the name is CHOWN ;-), which allow or deny a normal user (groups of user) to use the chown syscall (a'la SYSV vs. BSD). In all of my HP-sysadmin trainings, I say that at the time of quotas. Bye, ZGabor at CoDe dot HU PS: if I know well, there isn't any kernel parameter you have to change. (Well, I'd like to ask you to write me the name of it, as I don't know about it.) By the way you are right, the setprivgrp command isn't documented in HP's UNIX course docs (only in the HP-UX security), only in the manual. I know, I teach it. PS2: go away from fbsd-sec with this off-topic thread about HP-UX. There are more Unices, which has chown with AT&T semantics. Well, not so many with quotas (and FFS), as HP. -- #!/bin/ksh Z='21N16I25C25E30, 40M30E33E25T15U!' ;IFS=' ABCDEFGHIJKLMNOPQRSTUVWXYZ ';set $Z ;for i { [[ $i = ? ]]&&print $i&&break;[[ $i = ??? ]]&&j=$i&&i=${i%?};typeset -i40 i=8#$i;print -n ${i#???};[[ "$j" = ??? ]]&&print -n "${j#??} "&&j=;typeset +i i;};IFS=' 0123456789 ';set $Z;X=;for i { [[ $i = , ]]&&i=2;[[ $i = ?? ]]||typeset -l i;X="$X $i";typeset +l i;};print "$X" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Mar 18 8:36:14 1999 Delivered-To: freebsd-security@freebsd.org Received: from mail.euroweb.hu (mail.euroweb.hu [193.226.220.4]) by hub.freebsd.org (Postfix) with ESMTP id C73591546A for ; Thu, 18 Mar 1999 08:36:05 -0800 (PST) (envelope-from hu006co@mail.euroweb.hu) Received: (from hu006co@localhost) by mail.euroweb.hu (8.8.5/8.8.5) id RAA18419 for freebsd-security@freebsd.org; Thu, 18 Mar 1999 17:35:44 +0100 (MET) Received: (from zgabor@localhost) by CoDe.hu (8.8.8/8.8.8) id RAA00488 for freebsd-security@freebsd.org; Thu, 18 Mar 1999 17:23:42 +0100 (CET) (envelope-from zgabor) From: Zahemszky Gabor Message-Id: <199903181623.RAA00488@CoDe.hu> Subject: bug (?) in login limits from login.conf To: freebsd-security@freebsd.org Date: Thu, 18 Mar 1999 17:23:42 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi! I've found, that in my new 3.1RELEASE, there is an interesting bug in login(1) with the /etc/login.conf ttys.deny/host.deny/times.deny mechanism. (Well, I've found it on 2.2.5(?) and it works the same in 2.2.7.) If there are any login restrictions (time/host or line) in /etc/login.conf, login responds with: