Re: package security auditing and isolation

[Ted Zlatanov <tzz@lifelogs.com>]

On Thu, 06 Apr 2017 14:19:23 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

SM> Are you thinking of this to protect against accidental problems, or to
SM> protect against a malicious attacker?
>> To help code reviews find malicious changes.

SM> Then it's problematic: if it's a more or less standard procedure, you
SM> can assume than any attacker will know about it and will hence use
SM> workarounds to evade detection.

I don't buy that argument from either end. Right now, attackers need no
workarounds so the cost-benefit analysis is heavily in their favor.

SM> Such "heuristic detection" can only work via obscurity, either by
SM> keeping the reviewing criteria secret or making them somehow
SM> unpredictable (not sure what that could look like in this context).

We have to operate openly, because it's the only practical choice other
than forming a cabal or ignoring the problem. Heuristics are not what I
had in mind.

Here are some questions for the list:

a) Can the parse tree of a package be analyzed safely (without running
code in the package)? Is it deterministic?

b) If the parse tree of a package is analyzed, and only has whitelisted
functions such as `string-equal' in it, does that make the package safe?

c) Can the parse tree of a package be compared deterministically at two
separate VCS checkpoints to find what's changed?

d) Can the changes to the parse tree between two VCS checkpoints be
signed by a reviewer?

>> Can you elaborate on what could make it effective? Or, alternatively,
>> why the idea is fundamentally flawed and if there are better ones?

SM> Rather than try and detect dangerous patterns, we'd have to make
SM> "unsafe" behavior impossible, via something like isolation.
...
SM> Just trying to design the system will be a significant effort.
SM> I'm not really interested, sorry.

Right. Thanks for your comments.

Ted