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
[EMAIL PROTECTED] http://softweyr.com/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
