Date: Sat, 10 Feb 2001 15:31:12 -0700 From: Wes Peters <wes@softweyr.com> To: Robert Watson <rwatson@freebsd.org> 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: <3A85C130.1ED81BB5@softweyr.com> References: <Pine.NEB.3.96L.1010210103811.30518X-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3A85C130.1ED81BB5>