From owner-freebsd-hackers Mon Feb 24 16:38:21 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA04515 for hackers-outgoing; Mon, 24 Feb 1997 16:38:21 -0800 (PST) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA04506 for ; Mon, 24 Feb 1997 16:38:18 -0800 (PST) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.5/CET-v2.1) with SMTP id AAA08557; Tue, 25 Feb 1997 00:38:07 GMT Date: Tue, 25 Feb 1997 09:38:06 +0900 (JST) From: Michael Hancock To: Terry Lambert cc: FreeBSD Hackers Subject: Immutable files, a false sense of security (Re: disabling setuid , sh/csh) In-Reply-To: <199702242120.OAA25018@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 24 Feb 1997, Terry Lambert wrote: > If you were serious, you'd set all suid files to be immutable except > in single user mode, and all non-suid executables that run as root > from inetd or cron or whatever, etc.. There's no switch exported to the sys admin as in BSDI, NETBSD, and OPENBSD, so you would need to modify the source to use it. It gives a false sense of security according to few people on this list. Has anyone tried hacking a system in "secure" mode via something like /dev/io? I wonder how much of a speed bump it would present to an attacker. > You might even want to attribute files so that the only files that > had the "can execute" attribute bit are those which were set that > way after close by the linker (which would have to be suid to do > the job). > > If you were paranoid, any command that could ever be even potentially > run by root would need to be immutable as well, since it could write > a password entry or startup yp to allow remote password exposure... etc.. > > Better to just burn your whole system onto ROM, I suppose... Regards, Mike Hancock