new security doc using object-capabilities

Hi Brett,

Here are some comments on your proposal.  Sorry this took so
long.
I apologize if any of these comments are out of date (but
also look
forward to your answers to some of the questions, as
they'll help
me understand some more of the details of your proposal). 
Thanks!

> Introduction
> ///////////////////////////////////////
[...]
> Throughout this document several terms are going to be
used.  A
> "sandboxed interpreter" is one where the
built-in namespace is not the
> same as that of an interpreter whose built-ins were
unaltered, which
> is called an "unprotected interpreter".

Is this a definition or an implementation choice?  As in,
are you
defining "sandboxed" to mean "with altered
built-ins" or just
"restricted in some way", and does the above
mean to imply that
altering the built-ins is what triggers other kinds of
restrictions
(as it did in Python's old restricted execution mode)?

> A "bare interpreter" is one where the
built-in namespace has been
> stripped down the bare minimum needed to run any form
of basic Python
> program.  This means that all atomic types (i.e.,
syntactically
> supported types), ``object``, and the exceptions
provided by the
> ``exceptions`` module are considered in the built-in
namespace.  There
> have also been no imports executed in the interpreter.

Is a "bare interpreter" just one example of a
sandboxed interpreter,
or are all sandboxed interpreters in your design initially
bare (i.e.
"sandboxed" = "bare" + zero or more
granted authorities)?

> The "security domain" is the boundary at
which security is cared
> about.  For this dicussion, it is the interpreter.

It might be clearer to say (if i understand correctly)
"Each interpreter
is a separate security domain."

Many interpreters can run within a single operating system
process,
right?  Could you say a bit about what sort of concurrency
model you
have in mind?  How would this interact (if at all) with use
of the
existing threading functionality?

> The "powerbox" is the thing that possesses
the ultimate power in the
> system.  In our case it is the Python process.

This could also be the application process, right?

> Rationale
> ///////////////////////////////////////
[...]
> For instance, think of an application that supports a
plug-in system
> with Python as the language used for writing plug-ins. 
You do not
> want to have to examine every plug-in you download to
make sure that
> it does not alter your filesystem if you can help it. 
With a proper
> security model and implementation in place this
hinderance of having
> to examine all code you execute should be alleviated.

I'm glad to have this use case set out early in the
document, so the
reader can keep it in mind as an example while reading about
the model.

> Approaches to Security
> ///////////////////////////////////////
>
> There are essentially two types of security: who-I-am
> (permissions-based) security and what-I-have
(authority-based)
> security.

As Mark Miller mentioned in another message, your
descriptions of
"who-I-am" security and
"what-I-have" security make sense, but
they don't correspond to "permission" vs.
"authority".  They
correspond to "identity-based" vs.
"authority-based" security.

> Difficulties in Python for Object-Capabilities
> //////////////////////////////////////////////
[...]
> Three key requirements for providing a proper perimeter
defence is
> private namespaces, immutable shared state across
domains, and
> unforgeable references.

Nice summary.

> Problem of No Private Namespace
> ===============================
[...]
> The Python language has no such thing as a private
namespace.

Don't local scopes count as private namespaces?  It seems
clear
that they aren't designed with the intention of being
exposed,
unlike other namespaces in Python.

> It also makes providing security at the object level
using
> object-capabilities non-existent in pure Python code.

I don't think this is necessarily the case.  No Python code
i've
ever seen expects to be able to invade the local scopes of
other
functions, so you could use them as private namespaces. 
There
are two ways i've seen to invade local scopes:

    (a) Use gc.get_referents to get back from a cell object
        to its contents.

    (b) Compare the cell object to another cell object,
thereby
        causing __eq__ to be invoked to compare the contents
of
        the cells.

So you could protect local scopes by prohibiting these or by
simply turning off access to func_closure.  It's clear that
hardly
any code depends on these introspection featuresl, so it
would be
reasonble to turn them off in a sandboxed interpreter.  (It
seems
you would have to turn off some introspection features
anyway in
order to have reliable import guards.)

> Problem of Mutable Shared State
> ===============================
[...]
> Regardless, sharing of state that can be influenced by
another
> interpreter is not safe for object-capabilities.

Yup.

> Threat Model
> ///////////////////////////////////////

Good to see this specified here.  I like the way you've
broken this
down.

> * An interpreter cannot gain abilties the Python
process possesses
>   without explicitly being given those abilities.

It would be good to enumerate which abilities you're
referring to in
this item.  For example, a bare interpreter should be able
to allocate
memory and call most of the built-in functions, but should
not be able
to open network connections.

> * An interpreter cannot influence another interpreter
directly at the
>   Python level without explicitly allowing it.

You mean, without some other entity explicitly allowing it,
right?
What would that other entity be -- presumably the
interpreter that
spawned both of these sub-interpreters?

> * An interpreter cannot use operating system resources
without being
>   explicitly given those resources.

Okay.

> * A bare Python interpreter is always trusted.

What does "trusted" mean in the above?

> * Python bytecode is always distrusted.
> * Pure Python source code is always safe on its own.

It would be helpful to clarify "safe" here.  I
assume by "safe" you
mean that the Python source code can express whatever it
wants,
including potentially dangerous activities, but when run in
a bare
or sandboxed interpreter it cannot have harmful effects. 
But then
in what sense does the "safety" have to do with
the Python source code
rather than the restrictions on the interpreter?

Would it be correct to say:
  + We want to guarantee that Python source code cannot
violate
    the restrictions in a restricted or bare interpreter.
  + We do not prevent arbitrary Python bytecode from
violating
    these restrictions, and assume that it can.

>     + Malicious abilities are derived from C extension
modules,
>       built-in modules, and unsafe types implemented in
C, not from
>       pure Python source.

By "malicious" do you just mean "anything
that isn't accessible to
a bare interpreter"?

> * A sub-interpreter started by another interpreter does
not inherit
>   any state.

Do you envision a tree of interpreters and sub-interpreters?
 Can the
levels of spawning get arbitrarily deep?

If i am visualizing your model correctly, maybe it would be
useful to
introduce the term "parent", where each
interpreter has as its parent
either the Python process or another interpreter.  Then you
could say
that each interpreter acquires authority only by explicit
granting from
its parent.  Then i have another question: can an
interpreter acquire
authorities only when it is started, or can it acquire them
while it is
running, and how?

> Implementation
> ///////////////////////////////////////
>
> Guiding Principles
> ========================
>
> To begin, the Python process garners all power as the
powerbox.  It is
> up to the process to initially hand out access to
resources and
> abilities to interpreters.  This might take the form of
an interpreter
> with all abilities granted (i.e., a standard
interpreter as launched
> when you execute Python), which then creates
sub-interpreters with
> sandboxed abilities.  Another alternative is only
creating
> interpreters with sandboxed abilities (i.e., Python
being embedded in
> an application that only uses sandboxed interpreters).

This sounds like part of your design to me.  It might help
to have
this earlier in the document (maybe even with an example
diagram of a
tree of interpreters).

> All security measures should never have to ask who an
interpreter is.
> This means that what abilities an interpreter has
should not be stored
> at the interpreter level when the security can use a
proxy to protect
> a resource.  This means that while supporting a memory
cap can
> have a per-interpreter setting that is checked (because
access to the
> operating system's memory allocator is not supported
at the program
> level), protecting files and imports should not such a
per-interpreter
> protection at such a low level (because those can have
extension
> module proxies to provide the security).

It might be good to declare two categories of resources --
those
protected by object hiding and those protected by a
per-interpreter
setting -- and make lists.

> Backwards-compatibility will not be a hindrance upon
the design or
> implementation of the security model.  Because the
security model will
> inherently remove resources and abilities that existing
code expects,
> it is not reasonable to expect existing code to work in
a sandboxed
> interpreter.

You might qualify the last statement a bit.  For example, a
Python
implementation of a pure algorithm (e.g. string processing,
data
compression, etc.) would still work in a sandboxed
interpreter.

> Keeping Python "pythonic" is required for
all design decisions.

As Lawrence Oluyede also mentioned, it would be helpful to
say a
little more about what "pythonic" means.

> Restricting what is in the built-in namespace and the
safe-guarding
> the interpreter (which includes safe-guarding the
built-in types) is
> where security will come from.

Sounds good.

> Abilities of a Standard Sandboxed Interpreter
> =============================================
>
[...]
> * You cannot open any files directly.
> * Importation
>     + You can import any pure Python module.
>     + You cannot import any Python bytecode module.
>     + You cannot import any C extension module.
>     + You cannot import any built-in module.
> * You cannot find out any information about the
operating system you
>   are running on.
> * Only safe built-ins are provided.

This looks reasonable.  This is probably a good place to
itemize
exactly which built-ins are considered safe.

> Imports
> -------
>
> A proxy for protecting imports will be provided.  This
is done by
> setting the ``__import__()`` function in the built-in
namespace of the
> sandboxed interpreter to a proxied version of the
function.
>
> The planned proxy will take in a passed-in function to
use for the
> import and a whitelist of C extension modules and
built-in modules to
> allow importation of.

Presumably these are passed in to the proxy's constructor.

> If an import would lead to loading an extension
> or built-in module, it is checked against the whitelist
and allowed
> to be imported based on that list.  All .pyc and .pyo
file will not
> be imported.  All .py files will be imported.

I'm unclear about this.  Is the whitelist a list of module
names only,
or of filenames with extensions?  Does the normal
path-searching process
take place or can it be restricted in some way?  Would it
simplify the
security analysis to have the whitelist be a dictionary that
maps module
names to absolute pathnames?

If both the .py and .pyc are present, the normal import
would find the
.pyc file; would the import proxy reject such an import or
ignore it
and recompile the .py instead?

> It must be warned that importing any C extension module
is dangerous.

Right.

> Implementing Import in Python
> +++++++++++++++++++++++++++++
>
> To help facilitate in the exposure of more of what
importation
> requires (and thus make implementing a proxy easier),
the import
> machinery should be rewritten in Python.

This seems like a good idea.  Can you identify which minimum
essential
pieces of the import machinery have to be written in C?

> Sanitizing Built-In Types
> -------------------------
[...]
> Constructors
> ++++++++++++
>
> Almost all of Python's built-in types
> contain a constructor that allows code to create a new
instance of a
> type as long as you have the type itself. 
Unfortunately this does not
> work in an object-capabilities system without either
providing a proxy
> to the constructor or just turning it off.

The existence of the constructor isn't (by itself) the
problem.
The problem is that both of the following are true:

    (a) From any object you can get its type object.
    (b) Using any type object you can construct a new
instance.

So, you can control this either by hiding the type object,
separating
the constructor from the type, or disabling the constructor.

> Types whose constructors are considered dangerous are:
>
> * ``file``
>     + Will definitely use the ``open()`` built-in.
> * code objects
> * XXX sockets?
> * XXX type?
> * XXX

Looks good so far.  Not sure i see what's dangerous about
'type'.

> Filesystem Information
> ++++++++++++++++++++++
>
> When running code in a sandboxed interpreter, POLA
suggests that you
> do not want to expose information about your
environment on top of
> protecting its use.  This means that filesystem paths
typically should
> not be exposed.  Unfortunately, Python exposes file
paths all over the
> place:
>
> * Modules
>     + ``__file__`` attribute
> * Code objects
>     + ``co_filename`` attribute
> * Packages
>     + ``__path__`` attribute
> * XXX
>
> XXX how to expose safely?

It seems that in most cases, a single Python object is
associated with
a single pathname.  If that's true in general, one solution
would be
to provide an introspection function named 'getpath' or
something
similar that would get the path associated with any object. 
This
function might go in a module containing all the
introspection functions,
so imports of that module could be easily restricted.

> Mutable Shared State
> ++++++++++++++++++++
>
> Because built-in types are shared between interpreters,
they cannot
> expose any mutable shared state.  Unfortunately, as it
stands, some
> do.  Below is a list of types that share some form of
dangerous state,
> how they share it, and how to fix the problem:
>
> * ``object``
>     + ``__subclasses__()`` function
>         - Remove the function; never seen used in
real-world code.
> * XXX

Okay, more to work out here. 

> Perimeter Defences Between a Created Interpreter and
Its Creator
>
------------------------------------------------------------
----
>
> The plan is to allow interpreters to instantiate
sandboxed
> interpreters safely.  By using the creating
interpreter's abilities to
> provide abilities to the created interpreter, you make
sure there is
> no escalation in abilities.

Good.

> * ``__del__`` created in sandboxed interpreter but
object is cleaned
>   up in unprotected interpreter.

How do you envision the launching of a sandboxed interpreter
to look?
Could you sketch out some rough code examples?  Were you
thinking of
something like:

    sys.spawn(code, dict)
        code: a string containing Python source code
        dict: the global namespace in which to run the code

If you allow the parent interpreter to pass mutable objects
into the
child interpreter, then the parent and child can already
communicate
via the object, so '__del__' is a moot issue.  Do you want
to prevent
all communication between parent and child?  It's not
obvious to me
why that would be necessary.

> * Using frames to walk the frame stack back to another
interpreter.

Could you just disable introspection of the frame stack?

> Making the ``sys`` Module Safe
> ------------------------------
[...]
> This means that the ``sys`` module needs to have its
safe information
> separated out from the unsafe settings.

Yes.

> XXX separate modules, ``sys.settings`` and
``sys.info``, or strip
> ``sys`` to settings and put info somewhere else?  Or
provide a method
> that will create a faked sys module that has the safe
values copied
> into it?

I think the last suggestion above would lead to confusion. 
The two
groups should have two distinct names and it should be clear
which
attribute goes with which group.

> Protecting I/O
> ++++++++++++++
>
> The ``print`` keyword and the built-ins ``raw_input()``
and
> ``input()`` use the values stored in ``sys.stdout`` and
``sys.stdin``.
> By exposing these attributes to the creating
interpreter, one can set
> them to safe objects, such as instances of
``StringIO``.

Sounds good.

> Safe Networking
> ---------------
>
> XXX proxy on socket module, modify open() to be the
constructor, etc.

Lots more to think about here. 

> Protecting Memory Usage
> -----------------------
>
> To protect memory, low-level hooks into the memory
allocator for
> Python is needed.  By hooking into the C API for memory
allocation and
> deallocation a very rough running count of used memory
can kept.  This
> can be used to prevent sandboxed interpreters from
using so much
> memory that it impacts the overall performance of the
system.

Preventing denial-of-service is in general quite difficult,
but i
applaud the attempt.  I agree with your decision to separate
this
work from the rest of the security model.

-- ?!ng
_______________________________________________
Python-Dev mailing list
Python-Devpython.org
ht
tp://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/p
ython-dev/nessto%40sharedlog.com

new security doc using object-capabilities

Thread: new security doc using object-capabilities