From owner-freebsd-hackers Sat Feb 10 14:21:58 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id A10FE37B401; Sat, 10 Feb 2001 14:21:37 -0800 (PST) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 14RiXx-0000DM-00; Sat, 10 Feb 2001 15:31:13 -0700 Message-ID: <3A85C130.1ED81BB5@softweyr.com> Date: Sat, 10 Feb 2001 15:31:12 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Robert Watson Cc: Nick Sayer , Greg Black , kris@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: /etc/security: add md5 to suid change notification? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Robert Watson wrote: > > On Fri, 9 Feb 2001, Wes Peters wrote: > > > Add a list of executables and their MD5's to the kernel, to be loaded at > > boot time via the loader. Modify the kernel loader to refuse to exec > > any executable whose MD5 is known but doesn't match. Ditto for shared > > libraries and ld.so. There you have it, a system that cannot be > > upgraded except in single-user mode. > > Trouble is -- our shared library support is handled using memory mapping, > and not a function of the kernel itself, so it's not an action that can be > easily mediated by the kernel. The actual loading and mapping of files is performed by ld.so, right? This actually makes it easier, you can simply add the signature/cksum hacks into ld.so. > You could restrict memory mapping to only > files similarly approved, but that would break applications using mmap() > on data files. Ick. No. > MD5 execution restrictions also fail to prevent the > exploitation if I/O based vulnerabilities, or the use of scripted > languages. Right, but there are systems that don't allow scripted languages. Or at least carefully control it. They are a separate issue, that can be dealt with similarly, except it's hard to figure out where you stash the signature in a script program without affecting the signature of the script itself. > My feeling has always been that, without type-safe languages > and a move to static linking, execution limitations will be likely to fail > to provide a higher level of confidence in your system against a qualified > attacker. Yeah, I've toyed with the idea a few times before, but it makes the system very cumbersome to use. It might be useful in some highly controlled situations, where upgrades are done by exchanging hardware. > If you really want this behavior, consider tying it to securelevels > somehow, and adding a system flag that allows execution, and modifying > exec() to mask the execute bits with the presence of that flag, permitting > execution only if the flag is set, and limiting the setting of the flag to > low securelevels. You get about the same level of confidence (fairly > shaky but enough to confuse many attackers), and an easier implementation. And a lot less signature data floating about the system, waiting for a flipped bit. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message