Re: [SECURITY] Arbitrary code evaluation security in Org (was: [PATCH] ob-core: add org-confirm-babel-evaluate-cell custom variable)

[Ihor Radchenko <yantar92@posteo.net>]

Tim Cross <theophilusx@gmail.com> writes:

>> 1. Introduce a new customization `org-confirm-evaluate-safe-regexps'
>>    listing regexps that are considered safe or cons cells
>>    (src-body/header-arg/table/macro/diary . regexp)
>>
>> 2. Introduce a new customization `org-confirm-evaluate' that can be set
>>    to t/nil/prompt/safe/[function]/[alist]:
>>    - t/safe :: to display default prompt unless the code block in buffer is
>>                marked safe
>>    - prompt :: always ask (the prompt will then not display options to
>>                add current sexp to safe list)
>>    - [function] :: custom function that returns t/safe/prompt/[alist]
>>    - [alist] :: (src-body/header-arg/table/macro/diary/t .
>>                  t/safe/prompt/function)
>>                  (t . <value>) stands for default value.
>>
>> 3. The default prompt will mimic `org--confirm-resource-safe',
>>    additionally accepting Y/N to accept/decline all the evaluation in
>>    current command.
>>
>> This system will be used across Org for code evaluation. Old variables
>> will be supported, but obsoleted.
>>
>> WDYT?
>
> For many users who don't share org files, who work on a single user
> desktop and who implicitly trust the files they are working with, it is
> unlikely they want to be bothered by any of this. It should 'just
> work'. I suspect this is the majority. Others will have some sharing of
> documents - perhaps in a work group, a class or some form of team
> activity. The trust here is likely fairly high but perhaps not
> absolute. There is probably a need for some choice on execution on a per
> file basis. Finally, there are those org files which are from unknown
> and therefore untrusted sources - email messages, cloned git
> repositories, Emacs packages, etc. Most people likely don't want these
> executed by default and want to be asked or be able to block by default.

> The point is, we probably need to consider not only what variables are
> required, but also some infrastructure for managing those variables
> based on some form of document classification or trust. You touch on
> this with some of what has been outlined, but it focuses on the original
> data source. That information can be lost once a file has been
> retrieved. However, the trust level of that file likely doesn't change
> just because it now resides 'locally'.

Oops. I think I forgot to describe another point I was thinking about.

REGEXP in `org-confirm-evaluate-safe-regexps' may also be a cons cell
(SOURCE . REGEXP). SOURCE can be a file path, a directory containing the
file, or file contents hash. This way, we can mark whole files or
directories as safe. Or just specific code blocks in files or
directories.

> I do wonder if the idea of a document classification model and some form
> of heuristic algorithms to handle default document classification might
> be useful.

I do not think that we need to go in this direction.
I doubt that we are qualified to get the heuristics right.
Such things should either be maintained in Emacs core or not provided at
all to not create false sense of security.

Look at Emacs' approach to file-local variables.
There are no heuristics there.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>