NetBSD Problem Report #9359

Received: (qmail 2181 invoked from network); 6 Feb 2000 22:54:36 -0000
Message-Id: <200002062254.OAA19880@digital.clock.org>
Date: Sun, 6 Feb 2000 14:54:36 -0800 (PST)
From: "Erik E. Fair" <fair@digital.clock.org>
Reply-To: fair@netbsd.org
To: gnats-bugs@gnats.netbsd.org
Subject: there should be a script to set system files immutable
X-Send-Pr-Version: 3.95

>Number:         9359
>Category:       security
>Synopsis:       there should be a script to set system files immutable
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    security-officer
>State:          closed
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Sun Feb 06 14:57:00 +0000 2000
>Closed-Date:    Mon Jan 07 15:27:37 +0000 2008
>Last-Modified:  Fri Dec 19 20:25:01 +0000 2008
>Originator:     Erik E. Fair
>Release:        1.5 and later, maybe
>Organization:
International Organization of Internet Clock Watchers
>Environment:

System: NetBSD digital.clock.org 1.4.2_ALPHA NetBSD 1.4.2_ALPHA (DIGITAL) #10: Mon Jan 10 22:38:56 PST 2000 fair@doomsday.clock.org:/usr/obj/sys/arch/alpha/compile/DIGITAL alpha


>Description:
	There should be a script available which can "lock down"
	the installed default system using chflags(8) to set critical
	system files, binaries, etc to "system immutable."

	While this makes changing the system while running a very
	painful process, it can frustrate a system attacker who
	gains root access, only to find that the system must be
	brought down to single user mode in order to modify system
	binaries.

>How-To-Repeat:

>Fix:
	This implies creating and maintaining a list of files which
	are not supposed to change between NetBSD releases (e.g.
	/sbin/init), and possibly an additional list of files which
	are not supposed to change after installation (e.g. /netbsd,
	/etc/rc.conf). Some of it will be MD (e.g. bootstrap files).

	Perhaps this is something that mtree(8) should take care of.
>Release-Note:
>Audit-Trail:

From: "Dr. Lex Wennmacher" <wennmach@geo.Uni-Koeln.DE>
To: fair@digital.clock.org, gnats-bugs@gnats.netbsd.org
Cc:  Subject: Re: security/9359: there should be a script to set system files immutable
Date: Wed, 9 Feb 2000 09:40:35 +0100

 On Feb 6,  2:54pm, Erik E. Fair wrote:
 > Subject: security/9359: there should be a script to set system files immut
 >
 > >Number:         9359
 > >Category:       security
 > >Synopsis:       there should be a script to set system files immutable

 > [...]

 > >Description:
 > 	There should be a script available which can "lock down"
 > 	the installed default system using chflags(8) to set critical
 > 	system files, binaries, etc to "system immutable."
 >
 > 	While this makes changing the system while running a very
 > 	painful process, it can frustrate a system attacker who
 > 	gains root access, only to find that the system must be
 > 	brought down to single user mode in order to modify system
 > 	binaries.

 > [...]

 > >Fix:
 > 	This implies creating and maintaining a list of files which
 > 	are not supposed to change between NetBSD releases (e.g.
 > 	/sbin/init), and possibly an additional list of files which
 > 	are not supposed to change after installation (e.g. /netbsd,
 > 	/etc/rc.conf). Some of it will be MD (e.g. bootstrap files).
 >
 > 	Perhaps this is something that mtree(8) should take care of.

 The proposed functionality has been implemented into mtree(8) by mrg and myself
 a year ago (see the "-i" and "-m" options). mtree(8) can consistantly set and
 (at security level 0) reset sappnd and schg file flags.

 What we're lacking is a /etc/mtree/NetBSD.secure file. I proposed one on
 tech-security, I'll send it to you in private mail.


 Lex
From: Elad Efrat <elad@NetBSD.org>
To: gnats-bugs@netbsd.org
Cc: "Erik E. Fair" <fair@netbsd.org>
Subject: re: security/9359
Date: Sun, 14 Aug 2005 23:59:13 +0300

 This is part of the Veriexec features; read up on ``lockdown mode'':

 http://www.netbsd.org/guide/en/chap-veriexec.html#chap-veriexec-strict

 The use of chflags to achieve the goal of locking down a system by
 traversing an mtree specification file may be vulnerable to race
 conditions.

 Is it okay to close this PR?

 -e.

 -- 
 Elad Efrat
 PGP Key ID: 0x666EB914

From: matthew green <mrg@eterna.com.au>
To: gnats-bugs@netbsd.org
Cc: security-officer@netbsd.org, gnats-admin@netbsd.org,
	security-alert@netbsd.org
Subject: re: security/9359 
Date: Mon, 15 Aug 2005 11:36:49 +1000


     The use of chflags to achieve the goal of locking down a system by
     traversing an mtree specification file may be vulnerable to race
     conditions.


 what race conditions?


 i'd rather this PR was solved by providing the requested change
 not by saying "systrace can do all".  systrace is just another
 security tool to be used alongside chflags.


 .mrg.

From: Elad Efrat <elad@NetBSD.org>
To: mrg@eterna.com.au
Cc: gnats-bugs@netbsd.org
Subject: re: security/9359
Date: Mon, 15 Aug 2005 20:32:40 +0300

 The race conditions I'm referring to are that a loop to set the
 flags on the system is not an atomic operation; it does a chflags(2)
 call for each file.

 The proposed fix is to prevent an attacker who already gained root
 from doing any damage. Of course, this is based on the assumption
 that the admin caught the attacker on time and not after he's done.

 Given the situation, it's better to always have Veriexec load the
 files you care for and set it to work in strict level 1, IDS mode.
 If you identified an attacker in the system, you can quickly raise
 it to strict level 3, lockdown mode.

 I definately think that the suggested way of solving this PR is by
 using Veriexec. This is one of its design goals.

 And I never mentioned systrace. :)

 -e.

 -- 
 Elad Efrat
 PGP Key ID: 0x666EB914

From: matthew green <mrg@eterna.com.au>
To: Elad Efrat <elad@NetBSD.org>
Cc: gnats-bugs@netbsd.org
Subject: re: security/9359 
Date: Sat, 20 Aug 2005 00:25:24 +1000

    The race conditions I'm referring to are that a loop to set the
    flags on the system is not an atomic operation; it does a chflags(2)
    call for each file.


 i thought the whole purpose of this request was a wa lock down
 _before_ you start using it.  i don't get what this race condition
 is relevant for.


 .mrg.

From: Elad Efrat <elad@NetBSD.org>
To: matthew green <mrg@eterna.com.au>
Cc: gnats-bugs@netbsd.org
Subject: Re: security/9359
Date: Fri, 19 Aug 2005 17:20:56 +0300

 matthew green wrote:

 > i thought the whole purpose of this request was a wa lock down
 > _before_ you start using it.  i don't get what this race condition
 > is relevant for.

 If that's the case then you're right about no race, but unless you
 want to protect directories (such as /etc/rc.d) you should be using
 Veriexec.

 I'm volunteering to create a /etc/mtree/NetBSD.secure file with an
 explanation of what it is; as for a complete list of files on the
 system -- Brett and I are working on an fpgen(8) that will make this
 a pretty easy task, and can be used to generate a per-release list
 of file fingerprints.

 -e.

 -- 
 Elad Efrat
 PGP Key ID: 0x666EB914

Responsible-Changed-From-To: security-officer->elad
Responsible-Changed-By: elad@netbsd.org
Responsible-Changed-When: Fri, 19 Aug 2005 19:20:17 +0000
Responsible-Changed-Why:
I'll solve it.


From: Luke Mewburn <lukem@NetBSD.org>
To: gnats-bugs@netbsd.org
Cc: security-officer@netbsd.org, gnats-admin@netbsd.org,
	security-alert@netbsd.org
Subject: Re: security/9359
Date: Sat, 20 Aug 2005 13:07:46 +1000

 --2Bdqe1Grnm6v3UGK
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable

 On Fri, Aug 19, 2005 at 02:31:02PM +0000, Elad Efrat wrote:
   |  > i thought the whole purpose of this request was a wa lock down
   |  > _before_ you start using it.  i don't get what this race condition
   |  > is relevant for.
   | =20
   |  If that's the case then you're right about no race, but unless you
   |  want to protect directories (such as /etc/rc.d) you should be using
   |  Veriexec.
   | =20
   |  I'm volunteering to create a /etc/mtree/NetBSD.secure file with an
   |  explanation of what it is; as for a complete list of files on the
   |  system -- Brett and I are working on an fpgen(8) that will make this
   |  a pretty easy task, and can be used to generate a per-release list
   |  of file fingerprints.

 Can Veriexec use the sha1 fingerprints from /etc/mtree/set.* ?

 --2Bdqe1Grnm6v3UGK
 Content-Type: application/pgp-signature
 Content-Disposition: inline

 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.1 (NetBSD)

 iD8DBQFDBp6CpBhtmn8zJHIRAkP+AKCvuJ79n879euT9VmYRVnkj7JqQtQCgx5Ke
 LS1IyCKiBq+ffzzoUBXIOmA=
 =GCh5
 -----END PGP SIGNATURE-----

 --2Bdqe1Grnm6v3UGK--

From: Elad Efrat <elad@NetBSD.org>
To: gnats-bugs@netbsd.org
Cc: lukem@NetBSD.org
Subject: Re: security/9359
Date: Sun, 21 Aug 2005 00:06:18 +0300

 No, Veriexec has its own format for signature files.

 However, there are scripts that can be used to automate the
 generation of mtree spec files:

 ftp.netbsd.org/pub/NetBSD/misc/elad/gen-secure.sh
 ftp.netbsd.org/pub/NetBSD/misc/elad/gen-perms.sh

 The latter produced ``NetBSD.perms'' that can be found in the
 same directory.

 Note that the -n switch to ls was modified locally to print
 the file mode as a 4-digit number (instead of the 7 digits
 stat(1) gives).

 The fpgen(8) I was referring to will do the same, only for
 Veriexec.

 -e.

 -- 
 Elad Efrat
 PGP Key ID: 0x666EB914

From: "Erik E. Fair" <fair@netbsd.org>
To: NetBSD GNATS Problem Report Tracking System <gnats-bugs@netbsd.org>
Cc: 
Subject: Re: security/9359
Date: Sun, 20 Nov 2005 00:48:41 +0000

 My notion was that this file/binary lockdown would be done at system 
 installation/upgrade time, which is why I mentioned that 
 administration was kinda a pain - it means there's an extra step 
 before replacing any upgraded or changed binaries.

 The idea is that the system runs locked down all the time, so that if 
 an attacker managed either found a remote execution hole, or managed 
 a privilege upgrade while logged in, s/he still couldn't change the 
 binaries or libraries.

 All this PR was asking for was mechanism (done, in mtree(8)), and the 
 base list of files to be locked down that come with a NetBSD 
 distribution. The only race condition in this model/protocol is 
 between install and lockdown, and that should (if one is worried 
 about such things) be done with the system disconnected from the 
 Internet.

 	Erik <fair@netbsd.org>

State-Changed-From-To: open->feedback
State-Changed-By: elad@netbsd.org
State-Changed-When: Sat, 21 Jan 2006 22:52:31 +0000
State-Changed-Why:
the scripts exist. they are located in ftp.netbsd.org/pub/NetBSD/misc/elad/mtree/mtree.sh and secure.sh
they can be used to create mtree spec that can be fed to mtree -i.
do you want to use them or do you have a different solution?


Responsible-Changed-From-To: elad->security-officer
Responsible-Changed-By: elad@netbsd.org
Responsible-Changed-When: Thu, 02 Feb 2006 20:03:43 +0000
Responsible-Changed-Why:
my fixes were online for a while; back to the people who do security
for netbsd.


State-Changed-From-To: feedback->closed
State-Changed-By: elad@netbsd.org
State-Changed-When: Mon, 07 Jan 2008 15:27:37 +0000
State-Changed-Why:
fixes in pr, 2+ years feedback timeout. okay christos@, no objection from adrianp@.


From: Christos Zoulas <christos@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/9359 CVS commit: src/lib/libc/stdio
Date: Fri, 19 Dec 2008 20:20:48 +0000 (UTC)

 Module Name:	src
 Committed By:	christos
 Date:		Fri Dec 19 20:20:48 UTC 2008

 Modified Files:
 	src/lib/libc/stdio: fread.3

 Log Message:
 PR/9359: Chris Demetriou: Document fread/fwrite mixing behavior.


 To generate a diff of this commit:
 cvs rdiff -r1.12 -r1.13 src/lib/libc/stdio/fread.3

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

>Unformatted:

Home	PR Database Search