Re: package security auditing and isolation

[Ted Zlatanov <tzz@lifelogs.com>]

On Thu, 06 Apr 2017 10:48:20 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>> I propose two specific pieces of functionality, which I think are
>> essential to this task:
>> 
>> 1) tools for analyzing the source code and finding the function calls
>> that can be dangerous. This includes eval, calling the shell, etc.
>> 
>> I don't know how feasible this is, but IMHO it would be valuable. At the
>> very least it could make code reviews easier by focusing on the
>> potentially problematic sections. I think Emacs' core is the right place
>> to add such code, not modules or add-on packages.

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> It seems like it would be completely ineffective against a malicious
SM> attacker (especially if such an tool auditing is "standardized"), but
SM> I can't imagine it being very effective for the accidental case either.

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

The goal I stated is to "audit and isolate packages from modifying the
user's system... because any ELPA repository, its sources, and its
signing process can be compromised for at least a short time." If my
suggestion is ineffective, can you make suggestions to improve the
situation?

Another idea: add some UI in package.el to see what code changes are
getting installed with a package install update. That would be a quick
way to give users some visibility. It's not a solution, and it's poor
UI, but it's a start.

>> 2) establishing isolation levels in the C core.  Simply put, not all
>> packages need to be able to run shell commands, delete or modify files,
>> and so on.  When the user installs or updates a package, if the needed
>> access levels change, that should be noted and acknowledged.

SM> That could be done, but it's a major restructuring, which will probably
SM> require major changes to be able to isolate packages from each other.

If you, with your deep knowledge of the C core, could start a
*top-level* list of the necessary changes, that would be really helpful.

We don't have to do it all today, or this year. But we have to start
somewhere.

Ted