Date: Wed, 07 Aug 1996 18:35:41 -0400 From: James da Silva <jds@TracerTech.COM> To: Bruce Evans <bde@zeta.org.au> Cc: michaelh@cet.co.jp, Hackers@freebsd.org Subject: Re: kern_mib.c:int securelevel = -1; Message-ID: <199608072235.SAA02040@lex.tracertech.com>
next in thread | raw e-mail | index | archive | help
> >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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199608072235.SAA02040>