Re: Update _twisted completion

["Eric P. Mangold" <eric@xxxxxxxxxxxx>]

On Mon, Feb 04, 2013 at 12:31:56PM -0500, Phil Pennock wrote:
> On 2013-02-04 at 11:48 -0500, Eric P. Mangold wrote:
> > Other completions parse GNU --help output *shrug*. So I'm not really seeing
> > much of a difference here..
> 
> Pattern-matching on --help output and extracting strings to offer is
> different from evaluating code which can modify the shell environment.
> The child process can run anything itself, but that doesn't let it do
> things like change $XAUTHORITY and $DISPLAY in the shell, to silently
> repoint graphics interactions to a proxy, or set $http_proxy, or
> anything else that affects launched processes.  Or changing $SSH_ASKPASS
> to a wrapper which steals SSH key passphrases.

If you run a process via your shell, unless you have some kind of magic
sandbox I've never heard of, that process can stomp all over
your shell if it wants to.

If we're talking about malicious code, then you can't discount the power of
ptrace(2), /proc, etc.

> Software I really don't trust much gets run under passwordless sudo to
> an account where it has no access to my main working account.  (Software
> I don't trust at all obviously doesn't get run at all, or if I have no
> choice but to run it, then in a VM).
> 
> Even without that caution, trust flows down the path from parent to
> child processes.  Data coming back up the path should not become _code_
> coming back up the path.
> 
> When eval happens, it needs to be explicit (eval `ssh-agent -s`) and not
> happen because someone hit tab and didn't even ask for a command to be
> run.

Well, zsh ships our old stub, which loads arbitrary functions from the
Twisted directory and executes them.  Are you proposing to remove the
old stub? I'm not seeing any functional difference between the old and
new versions, from a security perspective :)
 
> When both completion function and program ship as part of one project,
> at least the completion function on disk can be read and audited and
> people can tell what will run inside their shell.

It's not different with Twisted's shell completion stub - it, and the python
code that gets executed, can be audited. And perhaps more easily
than if it were a huge convoluted shell script program.

If you upgrade your software, things could change - but that isn't really
any different than what we are used to.
 
> When the code comes from a program, which may be a compiled binary, your
> ability to audit and prove what you'll evaluate goes down significantly;
> the output might change depending upon the day of the month.

Yes - but that doesn't really apply exactly, to this particular function, as Twisted
doesn't include any binary programs, and all the source code is readily
available.

I mostly agree with everything you are saying - but I still think what we
are doing is acceptable, or at least *as acceptable* as what we've already
been doing. I'm very much open to doing things better, but I would need
some kind of concrete direction on what course to take. The problem of
allowing programs to dynamically supply their own, more-or-less arbitary,
completions in "safe" manner is certainly an interesting one.

The only mechanism provided by zsh is to "eval" the contents of a completion
function inside the user's shell, albeit in a "completion context". This works,
but provides for no safety between the consumer of completion functionality (zsh)
and the producer of completion functionality (in this case, a program).

It is already the case that programs, if "installed" can provide their own
completion functions by placing them in a "site-functions" directory.
Auditing these programs is still necessary as ever - if the program in question
delegates to some Python code to get its job done, I don't see that this
changes the fundamental nature of the problem...

If not "installed", then none of our Python code can hurt you. The completion
stub would fail because it would not find the command on the user's $PATH,
and the Python code in question could never be loaded because it doesn't
exist anywhere in sys.path.

And if you *have* "installed" Twisted, then presumably you already trust it, as
you've just contaminated your copy of Python with its modules.

Best regards,
-E