From owner-freebsd-security Sun Jun 14 13:49:09 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA27887 for freebsd-security-outgoing; Sun, 14 Jun 1998 13:49:09 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from burka.rdy.com (dima@burka.rdy.com [205.149.163.30]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA27790 for ; Sun, 14 Jun 1998 13:48:29 -0700 (PDT) (envelope-from dima@burka.rdy.com) Received: (from dima@localhost) by burka.rdy.com (8.8.8/RDY&DVV) id NAA06480; Sun, 14 Jun 1998 13:48:24 -0700 (PDT) Message-Id: <199806142048.NAA06480@burka.rdy.com> Subject: Re: bsd securelevel patch question In-Reply-To: from Niall Smart at "Jun 14, 98 11:23:53 am" To: njs3@doc.ic.ac.uk (Niall Smart) Date: Sun, 14 Jun 1998 13:48:24 -0700 (PDT) Cc: security@FreeBSD.ORG X-Class: Fast Organization: HackerDome Reply-To: dima@best.net From: dima@best.net (Dima Ruban) X-Mailer: ELM [version 2.4ME+ PL40 (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 Niall Smart writes: > On Jun 13, 11:03pm, Dima Ruban wrote: > Thats arguable, consider this quote from the D&I of 4.4BSD > > Files marked immutable include those that are frequently the subject > of attack by intruders (e.g., login and su). The append-only flag > is typically used for critical system logs. If an intruder breaks > in, he will be unable to cover his tracks. Although simple in > concept, these two features improve the security of a system > dramatically. > > I've already posted the following argument to bugtraq, but I'll repeat > it again here. > > Why do they advocate protecting login and su if such protection can > be trivially defeated using the same techniques we demonstrated in > the attack on inetd? And why do they claim these features improve the > security of a system "dramatically" if they can be bypassed so easily? > > What use are securelevels without propagating the immutable flag? The problem is - your patch doesn't fix anything. It just makes things more complicated. Example was already given, but here we go again: You make text segment of a program that marked immutable being a read-only. Excellent. In this case you need to make sure that such a process can't be killed or basically can't receive any signals. And this breaks the whole idea of signals. Because otherwise, being root, I can easily kill such a process and start another one with a back door in it. pid is not an issue - it can be easily faked to be the same as a target process. > > Niall > -- dima To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message