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>
index | next in thread | previous in thread | raw e-mail
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
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3A85C130.1ED81BB5>