eval vs. exec

[Delaney, Timothy]

> From: holger krekel [mailto:pyth at devel.trillke.net]
> 
> I've hear these type of arguments before. AFAIK bitter ex-employees
> don't need to write some exec/eval-exploit, they just use their old
> passwords or implant an easy backdoor on their last days. 
>
> Todays company's practices regarding security are often a *laugh*. 
> You try to close some mouses' hole but there are already several 
> open six-lane highways into the core of your system. This doesn't 
> neccessarily mean you don't need to care, though.

That's all true - but it's partially known as "covering one's arse". If
*you* haven't left the backdoor open, you're OK. The fewer back doors into a
place the better. Most security breaches in business are caused by employees
(both current and ex employees).

> But assume that your application wants to give the system 
> administrator
> means to inspect and test the objects in a running application. I
> wouldn't see the point of investing too much time on how to make it
> 'secure' (besides killing long-running mys-typed calculations). How
> secure can using a debugger get? At least I often start
> my python programs with 'python -i progname.py' which is a
> good application of 'exec/eval'.

Yes - in which case you (a) trust the employee and (b) close everything up
tightly behind them when they're gone. Oh - and (c) you verify as much as
possible that arbitrary strings aren't going to kill your system when
execed. How many debuggers allow entering arbitrary statements? Most allow
you to inspect, and change the value/binding of existing variables, but
don't allow executing arbitrary code.

> If your strings are coming from a public web-application 
> it's a different matter, of course. But not everything is
> a web-application.

In the particular case we are talking about, the strings are coming from an
external source - maybe not a public web application, but external
nonetheless.

There is always a tradeoff of convenience vs security. Security is not just
malicious - it's also about accidents. A classic case is teaching. Students
tend to make more mistakes than professionals. It is very important to limit
the amount of damage they can do. A large part of this is giving them an
environment which is "safe" - limited disk quotas and privilege levels. If
they *cannot* cause damage, no matter what they do, then by all means give
them unlimited eval/exec access. Just don't be surprised when you find
someone accidentally DOSing your mission-critical server because you forgot
to unplug the student server from the network.

Tim Delaney