On Fri, 8 Oct 2010 17:41:58 -0500 David Young <[email protected]> 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
