From owner-freebsd-hackers Wed Aug 7 15:35:50 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA14458 for hackers-outgoing; Wed, 7 Aug 1996 15:35:50 -0700 (PDT) Received: from tracer.tracertech.com (tracer.tracertech.com [205.147.164.65]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id PAA14453 for ; Wed, 7 Aug 1996 15:35:47 -0700 (PDT) Received: from lex.tracertech.com (lex.tracertech.com [205.147.164.70]) by tracer.tracertech.com (8.6.12/8.6.12) with ESMTP id SAA12029; Wed, 7 Aug 1996 18:35:44 -0400 Received: from localhost (localhost [127.0.0.1]) by lex.tracertech.com (8.6.12/8.6.12) with SMTP id SAA02040; Wed, 7 Aug 1996 18:35:42 -0400 Message-Id: <199608072235.SAA02040@lex.tracertech.com> X-Authentication-Warning: lex.tracertech.com: Host localhost didn't use HELO protocol To: Bruce Evans cc: michaelh@cet.co.jp, Hackers@freebsd.org Subject: Re: kern_mib.c:int securelevel = -1; Date: Wed, 07 Aug 1996 18:35:41 -0400 From: James da Silva Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >By the way, the comment is wrong on one important point: the > >disposition of this variable in bss vs data will be irrelevant to > >a cracker. If the kernel is not immutable, the variable can be > >patched either way. > > Not quite. The point is to patch the kernel that will be booted from. Indeed. If I'm a "skulking hacker" who can write to the kernel file, I can put the bss into the data segment, _then_ patch the variable with just a few more lines of code than it would take to patch the variable: ie simply modify the data and bss sizes in the header and extend the file with zeros. No? > However if the kernel is not immutable, a cracker could patch some of > the code that tests the variable. That too. It boils down to this: if the bootable kernel is writeable or repleaceable, then securelevel is easily defeated by a cracker, and if the kernel isn't writeable, then it doesn't matter whether securelevel is in data or bss. #ifdef SOAPBOX_MODE Thus, the comment in the systm.h just gives a false sense of security to anyone who reads it, puts securelevel in bss, and sits back feeling better about it. The holes related to securelevel are a mile wide. It would be interesting to see a serious, documented attempt to close them all. Until then, it should be labeled as experimental and off by default (as is the case now). The impression I've gotten is that securelevel was put in to play with filesystem-level support for append-only and immutable files, rather than as a concerted effort to really make BSD more secure. IMHO. #endif Jaime