[Tcl-bugs] [ tcl-Bugs-3027815 ] Safe interpreters can use Thread to execute unsafe commands

[SourceForge.net <no...@so...>]

Bugs item #3027815, was opened at 2010-07-10 17:26
Message generated for change (Comment added) made by vasiljevic
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=3027815&group_id=10894

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: 80. Thread Package
Group: obsolete: 8.5.8
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: kjnash (kjnash)
Assigned to: Zoran Vasiljevic (vasiljevic)
Summary: Safe interpreters can use Thread to execute unsafe commands

Initial Comment:
A safe interpreter can load all the commands of the Thread package.  This is a security issue, because it means that a safe interpreter can create a new thread and send commands to that thread's unsafe master interpreter:

% ::safe::interpCreate iSafe
iSafe
% iSafe eval pwd
invalid command name "pwd"
% iSafe eval {
    package require Thread
    set tid [thread::create]
    ::thread::send $tid {pwd}
}
/home/user
%

At present the safe entry point Thread_SafeInit gives a safe interpreter access to all the commands of the Thread extension.  For security reasons, at least some of these commands should be removed.

Perhaps safe interpreters should not be allowed any access to Thread commands.  I am not familiar with the whole of the Thread package, but it appears that the natural scope of a thread operation is the master interpreter of the thread.  If a safe interpreter needs limited access to Thread commands, it might be best provided by wrapper commands aliased into the safe slave from its unsafe master - not by loading the Thread package itself.

I suggest removing the safe entry point Thread_SafeInit completely.


----------------------------------------------------------------------

>Comment By: Zoran Vasiljevic (vasiljevic)
Date: 2010-09-28 20:55

Message:
This will now appoear in 2.6.7 patch release.

----------------------------------------------------------------------

Comment By: kjnash (kjnash)
Date: 2010-07-13 18:35

Message:
> Interesting point. Actually I could ask Tcl_IsSafe(interp) of the
> interp that creates the thread (the one that calls thread::create)
> and inherit that state in the new thread so its interp is also safe.
> Would that make sense?

That's an interesting suggestion!  However, file/network interaction is
normally added to a safe interpreter either by [interp alias] or by sharing
sockets: in both cases the slave is configured by its master (or higher
ancestor) in the same thread.  If there is no unsafe master, the slave
would be of limited value, except for computation.

If the Thread package were to add new mechanisms for using safe
interpreters, I think it would create a lot of work for the developers of
the Thread package, in particular the need to always be thinking about
whether Thread facilities will allow a safe interpreter to execute commands
in an unsafe interpreter (or, as Donal mentioned, a different kind of safe
interpreter).

However, such new mechanisms in Thread would not add much benefit, because
safe interpreters are not widely used, and users will tend to use the
safe-interpreter commands that they know, and will probably avoid using the
new capabilities in Thread because any extra capabilities will introduce
additional complications and security risks.

Also, as far as I know, it is unprecedented to have a safe interpreter as
the the root interpreter of a thread or process.  I don't know if it would
break anything.  It would impact on development of the core, because the
core developers would always have to consider the possibility that the root
interpreter may be safe.

I think the best solution is to remove the safe entry point
Thread_SafeInit completely.  As Donal said, let the master expose (safe)
aliases to operations as necessary.

Keith.


----------------------------------------------------------------------

Comment By: Donal K. Fellows (dkf)
Date: 2010-07-11 23:45

Message:
BTW, one safe context isn't the same as another because of the ability to
grant exceptions to the rules via aliases. It's possible for there to be
two sets of exceptions, each of which is safe on its own, but which are not
safe in combination. (Child interpreters of safe interpreters are a special
case; they start without any restricted operations at all and the parent
safe interpreter can't change that.) It's not ever going to be safe to
communicate between safe interps in different threads by default.

----------------------------------------------------------------------

Comment By: Donal K. Fellows (dkf)
Date: 2010-07-11 23:41

Message:
I suggest making thread creation a restricted operation and that a safe
interpreter should only be able to communicate with other interpreters that
it's master has permitted it to do so to (which would require a new
operation; sorry!)

But really, it would be better if there was some way for the (non-safe)
master to control messages sent (and what variables are shared, what
mutexes are available, etc.) more thoroughly. I've tended to assume that it
would be best if the thread extension simply wasn't marked as safe at all;
let the master expose (safe) aliases to operations as necessary.

----------------------------------------------------------------------

Comment By: Zoran Vasiljevic (vasiljevic)
Date: 2010-07-10 18:13

Message:
Interesting point. Actually I could ask Tcl_IsSafe(interp) of the
interp that creates the thread (the one that calls thread::create)
and inherit that state in the new thread so its interp is also safe.
Would that make sense?



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=3027815&group_id=10894