David A. Black <dblack / wobblini.net> wrote:
> Hi --
>
> On Sun, 9 Oct 2005, aurelianito wrote:
>
>>>> I hope this stops people from suggesting clever hacks (like the
>>>> one you just made). It's not about the clever hack. It's about how
>>>> do I declare it properly and enforce it.
>>>
>>> Don't worry -- I'm sure it will stop a number of people from
>>> continuing to try to help you.
>>
>> What I've tried to say is that I want to be able to declare the
>> security in other way. The way I want to do it is much more granular
>> and declarative. I'm not looking for a way to actually implement
>> evil.rb. I take it as it it is and stop it to do things than I don't
>> want to. That's a different security model.
>>
>> I'm really sorry if I offended you. That's not my intention and
>> please take my apologies. I'll try to write things in a way that I
>> don't offend any one else.
>
> It's OK -- I just think you may find that whatever you end up doing is
> going to be a clever hack anyway, so don't necessarily discard all of
> them :-)
>
> I wonder actually whether you will have to write a sort of pre-parser,
> and check the code itself, and then eval it.  And then of course
> create some configurable way to do this.

One major problem when checking code is that checking names is not 
sufficient.  IMHO you cannot solve this by changing the Ruby interpreter 
because you must trap into method calls for certain classes (File and Socket 
come to mind) and check which binary method actually gets called.  And that 
doesn't even deal with user defined C extensions - I gues you would have to 
prohibit them altogether.

> If you do, I guess it would be "do not allow" by default -- so that if
> someone tried to sneak in something bad (by doing some kind of
> scrambling or method renaming or something), it would just be ignored.

Although I agree from a security perspective that could mean that 
extensibility and maybe user defined classes suffer...

Regards

    robert