[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: package security auditing and isolation
From: |
Clément Pit-Claudel |
Subject: |
Re: package security auditing and isolation |
Date: |
Thu, 6 Apr 2017 16:17:17 -0400 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 |
On 2017-04-06 15:26, Ted Zlatanov wrote:
> a) Can the parse tree of a package be analyzed safely (without running
> code in the package)? Is it deterministic?
Yes if you mean the parse tree, but no if you mean the expanded syntax tree:
you need to run macros to see the full AST, and macros can run arbitrary code.
You could apply a first analysis pass to the macros, decide that they are safe,
expand, and run the analysis again; but see (b)
> 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?
Just looking at the parse tree isn't enough, because macros. The AST is
better, but still no: it's not hard to crash Emacs from ELisp, e.g. by causing
stack overflows. That would allow you to escape most protections, I expect.
Without going to such extremes, it's hard to think of what a good whitelist
would look like.
- package security auditing and isolation, Ted Zlatanov, 2017/04/06
- Re: package security auditing and isolation, Stefan Monnier, 2017/04/06
- Re: package security auditing and isolation, Yuri Khan, 2017/04/06
- Re: package security auditing and isolation, Ted Zlatanov, 2017/04/06
- Re: package security auditing and isolation, Stefan Monnier, 2017/04/06
- Re: package security auditing and isolation, Ted Zlatanov, 2017/04/06
- Re: package security auditing and isolation, Stefan Monnier, 2017/04/06
- Re: package security auditing and isolation, Ted Zlatanov, 2017/04/06
- Re: package security auditing and isolation, Tim Cross, 2017/04/07
- Re: package security auditing and isolation,
Clément Pit-Claudel <=