DE version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
43% Positive
Analyzed from 334 words in the discussion.
Trending Topics
#macro#safe#file#untrusted#macros#code#expansion#trust#scratch#permission

Discussion (5 Comments)Read Original on HackerNews
Macro expansion is data transformation. Form in, form out. Most macros are pure functions of their inputs. Even the ones that aren't seldom have effects that would allow exploitation. That's because a well-written macro does not have side-effects during expansion time, but instead generates code that when itself evaluated, has the desired effect.
The idea is that expanding an untrusted macro can be dangerous. This much is true. But the risky occurs only when both the macro and its expansion are untrusted. The vast majority of macros do not transform code in dangerous ways. It is perfectly safe to use these macros to expand untrusted forms to make flymake, find-function, and other features work correctly. To blanket-prohibit expansion even by macros doing obviously safe transformations is to misunderstand the issue.
At a minimum, it must be possible to define a macro and mark it safe for expanding untrusted code. Beyond that, it would be safe to run the macro-expander itself in an environment without access to mutating global operations. Since almost all macros are intrinsically safe to expand, we'd have far fewer situations in which people had subpar development experiences from overly conservative security mitigations.
In addition, after I've eval-buffered a file, that file (at least until reverted from disk) should be safe. I mean, if it were malicous, its malice would have manifested at the time it ran code as it was evaluated.
In Linux, sandboxing with Firejail and bwrap is quite easy to configure and allows fine-grained permissions.
Also, the new Landlock LSM and LSM-eBPF are quite promising.