Digitally Signed Binaries w/ Kernel support, etc.

[Kris Kennaway]

Peter Wemm wrote:
> On Fri, Apr 4, 2008 at 9:55 AM, Roland Smith <rsmith at xs4all.nl> wrote:
>> On Fri, Apr 04, 2008 at 10:58:40AM +0200, Ivan Voras wrote:
>>  > >> Signing binaries could be naturally tied in with securelevel, where some
>>  > >> securelevel (1?) would mean kernel no longer accepts new keys.
>>  > >
>>  > > If you set the system immutable flag on the binaries, you cannot modify them at
>>  > > all at securelevel >0. Signing the binaries would be pointless in that case.
>>  >
>>  > I think these are separate things. Modifying binaries is separate from
>>  > introducing new binaries. SCHG would prevent the former, but not the latter.
>>
>>  If you set the SCHG flag on the directories in $PATH, you can't put
>>  anything new there as well.
> 
> There's nothing magical about $PATH.  A person could put a malicious
> binary in /tmp or $HOME and run it with /tmp/crashme or whatever.
> Sure, you could set SCHG on every single writeable directory on the
> system to prevent any files being created.  MNT_NOEXEC might be an
> option.  The existence of script languages or even scriptable binaries
> does diminish the strength of a lockdown, but it depends on what
> you're trying to achieve.  eg: If you're trying to prevent your users
> from downloading a self-built irc client or bot and running it, then
> yes, requiring signed binaries would be useful.
> 
> In any case, there are legitimate uses for signed binaries.  But I'm
> not volunteering to do it.
> 

csjp@ had a mac_chkexec module that looks like it was never committed.

http://groups.google.com/group/mailing.freebsd.hackers/msg/074eec7def84c52b

Shouldn't be hard to update it.

Kris