From owner-freebsd-security Fri Oct 6 6: 4:16 2000 Delivered-To: freebsd-security@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id 371EE37B66D for ; Fri, 6 Oct 2000 06:04:13 -0700 (PDT) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id GAA19360; Fri, 6 Oct 2000 06:03:38 -0700 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda19358; Fri Oct 6 06:03:24 2000 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.11.0/8.9.1) id e96D3O048860; Fri, 6 Oct 2000 06:03:24 -0700 (PDT) Received: from cwsys9.cwsent.com(10.2.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdm48857; Fri Oct 6 06:02:46 2000 Received: (from uucp@localhost) by cwsys.cwsent.com (8.11.0/8.9.1) id e96D2k345593; Fri, 6 Oct 2000 06:02:46 -0700 (PDT) Message-Id: <200010061302.e96D2k345593@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdX45589; Fri Oct 6 06:01:59 2000 X-Mailer: exmh version 2.1.1 10/15/1999 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-OS: FreeBSD 4.1.1-RELEASE X-Sender: cy To: Hank Leininger Cc: freebsd-security@FreeBSD.ORG Subject: Re: BSD chpass (fwd) In-reply-to: Your message of "Thu, 05 Oct 2000 02:23:42 EDT." <200010050623.CAA05646@mailer.progressive-comp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 06 Oct 2000 06:01:59 -0700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <200010050623.CAA05646@mailer.progressive-comp.com>, Hank Leininger writes: > I've a feeling I'm (re)stating the obvious, but IMHO securelevels can't > really permanently preserve a system's known-good state in the face of root > compromise unless literally everything you'd ever access w/o securelevels > raised, is fully protected when they are (in which case you'll effectively > have everything interesting RO -- just set the RO jumper on the drive while > you're at it). Otherwise there will always(?) be some extra-mile way to > circumvent them. Of course we can devise countermeasures ad-nauseum -- for > instance, set all dirs in root's path to schg and only set sappnd on the > "last" one, and never change the order (silly). Or from every directory > "higher" in the path than a path'ed command, create a symlink to the right > place (unspeakably ugly, but works ;) Though you'll still have the 'sl', > 'ls-l', etc trojan possibilities either way. I think your first point is the only solution -- every R/O file would need the schg flag. Some co-workers and I had discussed this very issue about 2-3 years ago. The only solution we could arrive at was to burn the O/S onto a CDROM or set the R/O jumper on the drive, both of which would be administrative nightmares when the team administering the system is a ferry or helijet ride away, making managing such a system a very expensive proposition. Wouldn't setting schg on every binary and every config file on the system and running at securelevel 2 be equally effective? Then again there's the possibility of a bug in the system that would allow any attacker to reduce the securelevel. So once again were faced with your first point as the only solution. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/DEC Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message