[DGD] Re: Out of curiosity...

[Richard Braakman]

Mikael Lind wrote:
> A couple of suggestions regarding the security issue:
> 
> 1) Have filter_array() and similar add a prefix to the function, "func_" for
>    instance. Hardly my idea at all...

Yes, that approach worked well for some other constructs in IgorMUD. 
Unfortunately filter_array() and friends were too old and entrenched
to change that way.  (We did actually grep for usage, to see if we
could change them all.  There were more than 10000 hits.)

Instead of a generic "func_", I would use "filter_".  And there should be
a list of these prefixes, so that people can know to avoid them.

> 2) Do a check similar to:
> 
> static varargs mixed *filter_array(mixed *arr, string func, mixed args...) {
>     [...]
>     if (function_object(func, this_object()) != previous_program()) {
> 	error("Function not defined by calling program");
>     }
>     [...]
> }

Hmm, I see that your filter_array has no provision for calling the function
in another object.  That simplifies the check considerably :)

Igor's version checks that the function is not called in a "sensitive"
object, and that it's not defined in the auto object.

These checks are not very expensive, because they only occur once per
filter_array or map_array call.  The badness was in two related
functions, filter_relay and map_relay.  These take a function name and
an array of objects, and call the function in each of those objects.

Very useful, but because they are defined in the auto object, we had
to do the security check for every call.  

> 3) Remove filter_array() and similar and use regular loops instead.
>    Tick-sucking objects can be precompiled. I think this is the cleanest
>    solution. Probably only an option at design level.

That is a matter of preference.  I happen to be a functional-languages
fan :) (I miss closures and anonymous functions in DGD.)

> If 2) is used, I think that function_object(), this_object(),
> previous_program() and perhaps also error() need to be made nomask. Masking
> security functions is as far as I know a rather easy way of breaking
> security.

They should be made nomask if you do redefine them, but you don't need
to redefine them just for that.  kfun calls stay kfun calls, even if
an inheriting object tries to redefine the kfun.

Richard Braakman



List config page:  http://list.imaginary.com/mailman/listinfo/dgd