From owner-freebsd-security Mon Nov 1 8:55:27 1999 Delivered-To: freebsd-security@freebsd.org Received: from anarcat.dyndns.org (phobos.IRO.UMontreal.CA [132.204.20.20]) by hub.freebsd.org (Postfix) with ESMTP id 729EE152CF; Mon, 1 Nov 1999 08:55:11 -0800 (PST) (envelope-from spidey@anarcat.dyndns.org) Received: by anarcat.dyndns.org (Postfix, from userid 1000) id 8A3AA1BDA; Mon, 1 Nov 1999 11:56:04 -0500 (EST) From: Spidey MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14365.50723.872972.30971@anarcat.dyndns.org> Date: Mon, 1 Nov 1999 11:56:03 -0500 (EST) To: Eivind Eklund Cc: freebsd-security@FreeBSD.ORG Subject: Re: Examining FBSD set[ug]ids and their use References: <14364.64172.638014.558487@anarcat.dyndns.org> <19991101173955.L72085@bitbox.follo.net> X-Mailer: VM 6.72 under 21.1 "20 Minutes to Nikko" XEmacs Lucid (patch 2) Reply-To: Spidey Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --- Big Brother told Eivind Eklund to write, at 17:39 of November 1: > On Sun, Oct 31, 1999 at 09:27:56PM -0500, Spidey wrote: > > # The suid bit is NOT necessary for any usage I could find... > > df gname=operator mode=2555 > > The suid bit is necessary for users to be able to inspect the amount > of disk space free on unmounted disks. I must be missing something here. When a disk is unmounted, it does not appear in the df output, no? > Personally, I don't think users should be allowed to see the amount of > disk space free on unmounted disks unless they are in group operator > themselves. > > If I don't get any disagreement, I will remove this setuid bit. I agree. > > # High scores management > > sol uname=games gname=games mode=6755 > > This looks like a bug in some port, actually. We shouldn't normally > have anything that is setuid games, only setgid. Oh. And why? BTW, there's also cconq, xconq and yamsweeper that are setuid gnames. > > # Allow users to read master.passwd > > xlock mode=4111 > > A separate system for verifying a user's own password would be > infinitely desirable. I suggest something as simple as a small > executable that verify the password, and automatically touch a file so > it can't be called more than reasonable for interactive verification. Yes. I found very surprising that xlock would _need_ to be setuid... > > # Allow users to regenerate the aliases database. > > # Why the hell should anyone else than the one that has modified the > > # database would want to rebuild it???? > > newaliases > > The alias files can be group writable. But it is not by default. So I don't think that newaliases should be suid. But we miss the point here anyways: newaliases is a link to sendmail, so... > > # Same as rsh and such. > > ssh1 mode=4711 > > Not quite. ssh uses this to get at the local host key, and > authenticate that it is run with that key or the attacker has control > over the entire host (by using a privileged port as the source port). Ok. You know it.. :) I will correct some stuff, I think... -- Si l'image donne l'illusion de savoir C'est que l'adage pretend que pour croire, L'important ne serait que de voir Lofofora To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message