> An alternative, whicn may not be perfect, but at least available
> without prejudice, is to use the fact that you're using an
> interpreter, where all system calls are made through a wrapper. This
> gives you a lot more control over what you allow and what not. "Safe"
> versions exist of Tcl, Scheme and Perl (in a sense -- I don't know if
> taintperl uses the same approach). Let's consider what would be
> necessary to create a safe version of Python. (I haven't read any of
> the docs on Safe-Tcl, so maybe I'm missing some good ideas -- if so,
> please tell me!)
All of the existing or proposed systems I know of ( except, I believe,
taintperl - which is based on a much more limited idea of safety. )
either make use of a restricted interpreter, or an Object-Oriented
Capability system, or both.
chroot is not acceptable for several reasons. ( One more is that it's
unix specific. )
> I'd like to design a general architecture for restricting the damage
> that built-in functions can do.
>
> The first thing to do is making an inventory of potentially dangerous
> built-in functions. [ ... ]
Rather than guarded functions, I think the more general and flexible
methods would be to implement safety on a module basis by changing
import. ( Mandatory Disclosure of Bias: I've already been planning
on developing a new import *function* , as a prototype for eventual
changed in the builtin import *statement* - to incorporate the
import-from-pathname & import-as-name capability I posted in
newmod/ImportModule, and the sort of import-from-url that Ken and
the NIST folks have played around with. ( plus my addition of
supporting mime-types on import-by-url: Content-Types:
application/x-python-pycode, application/x-python-source & text/html).)
This would require some change to both import, and how builtin modules
( both __builtin__, and, generically, builtin, C-coded, compiled object
modules. ) work.
Any module that imports another module should be able to restrict that
modules allowable import "path" ( in quotes, because I don't *just* mean
$PYTHONPATH, but the whole set of allowable modules. )
Thus, I should be able to generically control exactly what 'open' function
is used. If a module advertises that it doesn't have to do any I/O,
then I can map all open's ( read or write ) to null operations.
Alternatively, I can map open to a function that allows only read access,
after the appropriate checks, one that allows write, but prepends '/tmp'
and strips any "/.." out of pathnames, or one that pops up a query:
"Module XXX request open access=r of pathname "/etc/passwd" -- Allow [Y/N] ?:"
We also need to allow passing IN of objects. Another way of
restricting what foreign modules can do, is the "capability"
method: Rather than giving it a restricted form of 'open', a
more effective way of limiting it is to not allow open at all,
but to give it a handle to a file object that has already been
opened with the correct restrictions. ( actually, here I've been
thinking more about sockets than files: some agents may have to
do some sort of "rendezvous" . We may not want to give them
the capability to "import socket" and do anything they desire
with it, but instead, hand them a sort of inactive (potential)
socket object which they can activate when they are ready.
> Note that I don't address the first category of attacks (resource
> over-use and exploiting bugs). I've just doen a grep for all
> occurrences of scanf, str(n)cpy, str(n)cat and found only two unsafe
> places that can easily be exploited from Python -- both in import.c,
> and one in AIX-specific code (it had the wrong idea of what the length
> passed to strncpy does).
Oops!
If it's in AIX-specific import, then I suppose the finger points at me!
<embarassed grin :->
> My questions right now are:
>
> - Do you have a need for this -- would you use it?
Yes. Definitely. In fact, figuring out this problem has been what's
stalled work on a Web based distributes Python library,browser and
literate-programming/documentation system I proposed. ( The NIST code
defines a "trusted netpath" from which modules will be allowed to be
imported - which Ken Manheimer, or whoever at NIST is responsible
for writing up that page, admits is only a limited and temporary
solution. )
> - Do you think it can be made safe enough?
Yes.
> - Are there holes in my approach?
>
> - Do you like my approach?
>
> - Can you think of a better name for guarded_exec()? (I don't like
> rexec since it sounds too much like remote exec.)
>
> - Do you know of any potentially unsafe situations (i.e. bugs :-)in
> the current Python code, like the recursion I mentioned in repr() and
> print?
>
Discussion above and to follow...
> - Would you like to help implementing this? (In that case you'll need
> to provide a PGP key :-)
Yes. ( I'll get one ASAP )
> - Anyone know enough about the approaches other languages are taking
> to summarize how they do it?
I previously posted some pointers to some other references.
( I can't say I have digested them all well enough to acurately
summarize them, but if I can manage the time, I'll try! I've
been trying (haltingly, since there are other things I'm SUPPOSED
to be doing) to digest the ILU stuff from Xerox and get Modula-3
and oblique ported to AIX. My understanding of some of this stuff
is limited until I actually try to use it. For example, after
reading the safe-tcl descriptions several times, I still find
myself unconvinced that it, in fact, *does* deliver the safety it
claims to without serious restrictions. But that may well be my
lack of understanding of the model. I'll have to just go ahead and
try it to either convince myself that it DOES work, or demonstrate
how it doesn't. )
safe-tcl,Obliq,Telescript, ILU ( and the whole world fo COBRA/DSOM
distributed objects )
Ken Manheimer (at NIST) and Dan Connolly are the others who have
tried hacking-at/thinking-about the problem. ( And I know Paul
Everitt and a few others are real interested... )
Note: This month's (October) BYTE has a cover article on "Smart Networks"
about AT&T and IBM's intellegent Agents projects. ( Just got it yesterday
so I only glaced thru it. )
-- Steve Majewski (804-982-0831) <sdm7g@Virginia.EDU> --
-- UVA Department of Molecular Physiology and Biological Physics --
-- Box 449 Health Science Center Charlottesville,VA 22908 --
[ "Cheese is more macho?" ]