Ideas to optimize this getitem/eval call?

[Steven D'Aprano]

On Sat, 03 Jan 2009 04:14:14 -0800, mario wrote:

> On Jan 3, 7:16 am, Steven D'Aprano <st... at REMOVE-THIS-
> cybersource.com.au> wrote:
[...]
>> I must say though, your choice of builtins to prohibit seems rather
>> arbitrary. What is dangerous about (e.g.) id() and isinstance()?
> 
> Preventive, probably. I also feel that temlates should have any business
> with info such as the memory addressed returnred by id(). For
> isinstance, becuase it is somewhat related to __subclasses__ that is
> known to be insecure.

It's that "probably" that worries me.

In my earlier post, I was going to say "your choice of builtins to 
prohibit seems rather Cargo Cult-ish", but I decided that might be a bit 
rude, and I decided to give you the benefit of the doubt. But your answer 
here doesn't really give me any more confidence.

What security issues do you think you are preventing by prohibiting id()? 
It is true that the id returned is a memory address in CPython, but 
that's a mere implementation detail, and may not be true in other 
implementations. Even if it is a memory address, so what? You can't do 
anything with it except treat it as an integer. I don't see how id() 
decreases security one iota.

In the absence of even a theoretical threat, banning a function that 
returns an int because the int is derived from a memory address (but 
can't be used as one!) makes you appear to be engaging in Cargo Cult 
programming: following the ritual, without any understanding of what you 
are doing.

http://catb.org/~esr/jargon/html/C/cargo-cult-programming.html

Sorry to be so harsh, especially over such a tiny little thing as the 
id() function, but that's the impression it gives me, and I'm probably 
not the only one. It is true that a false positive (needlessly banning a 
harmless function) has less serious consequences than a false negative 
(failing to ban a harmful function), but it does reduce confidence that 
you know what you're doing.

Likewise for isinstance() and issubclass(). They may be related to 
__subclasses__, but they don't give the caller access to __subclassess__. 
So what is the actual threat you are defending against?

I'm not saying that there must be an actual in-the-wild demonstrated 
vulnerability before you prohibit a built-in, but there should be at 
least a plausible attack vector.


 
> Incidentally, I updated the page you point to clarify what is going on.

Speaking of that page, you have an obvious typo ("teh" instead of "the") 
that should be fixed:

"In addition to teh above, all subclasses of BaseException..."

http://evoque.gizmojo.org/usage/restricted/




> I also added a link to Brett Cannon's inspiration paper on the topic of
> securing the python interpreter...
> 
>> >     except:
>> >         # KeyError, NameError, AttributeError, SyntaxError, #
>> >         ValueError, TypeError, IOError
>>
>> If you want to capture seven exceptions, then capture seven exceptions,
>> not any exception.
> 
> Absolutely not. I want to catch ALL evaluation exceptions...

I see. It wasn't clear that this was deliberate, I read it as if there 
was a fixed, finite list you wanted to catch, and nothing else. You 
should make sure this is clearly documented in your code.



-- 
Steven.