From owner-freebsd-hackers Sat Feb 10 7:43:27 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 3D2DD37B65D; Sat, 10 Feb 2001 07:43:06 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.1/8.11.1) with SMTP id f1AFgJh63543; Sat, 10 Feb 2001 10:42:23 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Sat, 10 Feb 2001 10:42:19 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Wes Peters Cc: Nick Sayer , Greg Black , kris@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: /etc/security: add md5 to suid change notification? In-Reply-To: <3A84D3F7.1CCE62A3@softweyr.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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. You could restrict memory mapping to only files similarly approved, but that would break applications using mmap() on data files. MD5 execution restrictions also fail to prevent the exploitation if I/O based vulnerabilities, or the use of scripted languages. 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. 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. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message