Re: [ANN] Lunatik -- NetBSD kernel scripting with Lua (GSoC project

[Matthew Mondor <mm_lists%pulsar-zone.net@localhost>]

On Fri, 8 Oct 2010 17:41:58 -0500
David Young <dyoung%pobox.com@localhost> wrote:

> A signature only tells you whose neck to wring when the script
> misbehaves. :-) Since a Lua script running in the kernel won't be
> able to forge a pointer (right?), or conjure references to methods or
> data that weren't in its environment at the outset, you can run it
> in a highly restricted environment so that many kinds of misbehavior
> are difficult or impossible.  Or I would *think* you can restrict the
> environment in that way; I wonder what Lourival thinks about that.

I agree that sandboxing (access to the minimal required
environment/APIs/KPIs) and interpreter-level security measures
(resources usage, loop preemption if need be) are good practice.  I
however think that signature verification would provide more than only
key to vendor mapping, as it could prevent loading of untrusted code.
Admitedly this is a non-issue for now, as any likely script/module are
presently part of the base distribution.

I was thinking more in the sense of a possible future proactive
software management tool that could perform (semi-)automatic upgrades,
but afterall, the first step would probably be to make sure that such a
software manager utilizes signature verification itself, which would be
easier and probably enough for most uses.

And after thinking more about it, although in-kernel signature
verification might even help against local module/script forging
exploits, this would only be true if the trusted public keys were
linked in with the image, were in a read-only memory segment, and if
the kernel image itself was read-only (either loaded from read-only
media, or enforced read-only by software policy like securelevel).
This seems overly complex for common setups...  Perhaps useful for some
embedded cases?  Although even then, it's probably simpler to keep
using a monolithic kernel for those.

Which makes me wonder: should there be a feature to optionally link
kernel-level scripts with the kernel image, so that with monolithic
setups, file system script loading could be disabled, without affecting
future functionality that might depend on kernel-space Lua scripts?  By
extension, perhaps that kernel-space scripts could be provided as part
of kernel modules, which can already be either built monolithic or
modular.  I know linking text (or bytecode) blobs after an objcopy step
would be easily, as well as mapping them to names which a loader can
look for, but I'm not familiar enough with the new modular system to
know if this is realistic without too much effort.

Thanks,
-- 
Matt