Re: package security auditing and isolation

[Stefan Monnier]

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.

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

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

Unless workarounds are *really* difficult or impossible, of course.
But in the current Emacs design, I'd expect any need for a workaround
would be trivial to satisfy (e.g. call (intern (concat "shel" "l-command"))
to avoid detection) or end up making it more difficult for the
non-malicious packages to do their job.

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

Rather than try and detect dangerous patterns, we'd have to make
"unsafe" behavior impossible, via something like isolation.

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.

Just trying to design the system will be a significant effort.
I'm not really interested, sorry.


        Stefan