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

[Lourival Vieira Neto <lourival.neto%gmail.com@localhost>]

On Fri, Oct 8, 2010 at 7:41 PM, David Young <dyoung%pobox.com@localhost> wrote:
> On Wed, Oct 06, 2010 at 07:14:48PM -0400, Matthew Mondor wrote:
>> On Wed, 6 Oct 2010 16:12:28 -0500
>> Javier Guerra Giraldez <javier%guerrag.com@localhost> wrote:
>>
>> > just curious, why was that needed?   is floating point forbidden by
>> > code conventions?
>>
>> As for possible problems like stack usage, I guess that if it's running
>> under an LWP context it probably is less restricted, but I agree that
>> preventing interpretation of non-trusted scripts would be better than
>> trying to cripple the Lua runtime as much as possible.  Considering
>> that the cryptographic code export is now less restrictive than it used
>> to be, possibly that signature checking would also be nice to have,
>> other than only limiting access to the superuser.
>
> 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 wouldn't say better =). That's exactly how I'm thinking about
address this issue: restricting access to each Lua environment. For
example, a script running in packet filtering should have access to a
different set of kernel functions than a script running in process
scheduling. Moreover, we could restrict also the access for users
loading scripts. For example, we could accept only scripts loaded by
users from the "scheduler" group for defining a scheduling script.

Cheers,
--
Lourival Vieira Neto