Date: Sat, 10 Feb 2001 10:42:19 -0500 (EST) From: Robert Watson <rwatson@freebsd.org> To: Wes Peters <wes@softweyr.com> Cc: Nick Sayer <nsayer@quack.kfu.com>, Greg Black <gjb@gbch.net>, kris@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: /etc/security: add md5 to suid change notification? Message-ID: <Pine.NEB.3.96L.1010210103811.30518X-100000@fledge.watson.org> In-Reply-To: <3A84D3F7.1CCE62A3@softweyr.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1010210103811.30518X-100000>