Re: [PATCH] ob-core: add org-confirm-babel-evaluate-cell custom variable

[Tim Cross]

Ihor Radchenko <yantar92@posteo.net> writes:

> Tim Cross <theophilusx@gmail.com> writes:
>
>> Based on the information in section 17.13, how do I configure my Emacs
>> so that
>>
>> 1. All the code in the files I wrote just runs and doesn't bother me with
>> annoying execute questions.
>>
>> 2. Code in files from colleagues is shown to me and I'm asked if it
>> should be executed. Once I say yes, I don't want to be bothered about it
>> again i.e. next time I open that file, I want org mode to know I trust
>> it.
>>
>> 3. Absolutely no code in files which are not from the two preceding
>> sources is to be executed unless I explicitly approve it. 
>
> Not yet, but I hope that we can integrate the approach we use in
> `org-safe-remote-resources' and `org--confirm-resource-safe'.
>
>> It feels like what we currently have is a selection of disconnect knobs
>> which the user can tweak, but with no over-arching mechanism to help
>> manage these settings for various scenarios.
>
> Agree. I hope that we can slowly work towards connecting these knobs.
>
>> Finally, are we 100% certain that these different code evaluation
>> circumstances are the only ones? Can we be certain there isn't areas
>> where options or variables are set which couldn't be used to evaluate
>> code (similar to be previously identified execution of code in block
>> headers which occurred before the checks on code evaluation?)?  
>
> No, we can't. But it is true for any software that allows third-party
> code, not just for Org or even Emacs.
>

Yes, you are right there are no guarantees. However, I do feel that if
we are going to add this security layer, we also need to perform some
form of audit and documentation of the specific points where org
constructs will/can trigger evaluation of included code. As the bug with
rich text demonstrated, there will likely be corner cases we
miss. However, we should at least try to identify as many as possible
and document them (and include automated tests when possible).

One of the downsides regarding improved security controls is that it
raises the level of expectations. We need to try and ensure we meet
those expectations. What we really need are some good ethical hackers to
help us identify potential 'hot spots'. The ability to do this
effectively does involve a particular type of mind set and skills not
necessarily common amongst most users. 

> And we cannot use the more universal sandbox approach either. Not in
> Emacs.
>
>> It also feels like the approach we have taken here is almost a throwback
>> to a past era where he had a lot more trust. What we seem to have is
>> protection against accidental execution of code rather than protection
>> against code with malicious intent which has been crafted to be
>> difficult to spot and deliberately takes advantages of small 'holes' or
>> over-sight in the controls supplied.
>
> I do not think that we can do anything about crafted code in Emacs other
> than displaying that code and letting the user decide.
>

Agreed. What we need next is the ability to track those decisions so
that the user isn't nagged about the same things every time and the
ability to set different defaults based on some preference (such as
source/origin, location, etc. 

> And I haven't seen any better solution, except anti-virus scanners that
> are constantly fighting new malicious code.
>
> At least, we do show the code. It is already better than "yes/no"
> dialogue you get when running random executable on Windows.

Agree. The question is whether we actually do provide that y-n and
display in sufficient situations. 

Given the additional information you provided, I'm somewhat less
concerned.

These 'knobs' definitely do need some form of additional abstraction
which will more easily allow end users to set a basic policy regarding
the treatment of different org files or org files from different
sources. I suspect, in the long-term, we are likely to need some type of
file 'cookie' i.e. a local-variable setting which will either set the
policy for that file or set the origin/source/trust level etc so that whatever
security policy the user has defined can be applied. IN some ways,
similar to the 'cookie' placed into your custom variables when you say
you trust some new theme.