From: Tim Cross <theophilusx@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: [PATCH] ob-core: add org-confirm-babel-evaluate-cell custom variable
Date: Fri, 16 Dec 2022 08:08:28 +1100 [thread overview]
Message-ID: <86len8uxmu.fsf@gmail.com> (raw)
In-Reply-To: <tnfc04$bv0$1@ciao.gmane.io>
Max Nikulin <manikulin@gmail.com> writes:
> On 15/12/2022 19:25, Ihor Radchenko wrote:
>> Max Nikulin writes:
>>
>>> I would consider reverting the commit causing user prompt for every
>>> variable.
>> I disagree. If anything, we can set the default value of
>> `org-confirm-babel-evaluate-cell' to nil and apply this patch.
>> Then, we can get the old behaviour back yet allowing concerned users to
>> have more security.
>
> I am leaving it up to you. Form my point of view it will be dead code that increases
> complexity with no practical outcome. Unfortunately setting
> `org-confirm-babel-evaluate-cell' to anything other than nil results in annoyance rather
> than security.
>
> Perhaps advising `org-babel-execute-src-block' with `y-or-n-p' is a better treatment for
> my paranoia.
>
>> This patch does not only affect src blocks. It affects all the users of
>> `org-babel-read'.
>
> Mostly it is called with INHIBIT-LISP-EVAL set to t.
>
>>> https://list.orgmode.org/Y1uFDWOjZb85lk+3@protected.localdomain
>>> Re: [BUG][Security] begin_src :var evaluated before the prompt to
>>> confirm execution
>> How is it related to the current discussion?
>> The purpose of the security feature discussed here is not for web
>> browsers or anything like that.
>
> I am not going to add malicious source blocks to my private org files. For some code it is
> better to have a prompt, but generally the issue is not excessively important. I tend to
> inspect org files fetched from net in some other application at first (browser, less, or
> vim).
>
While I would argue that is a good practice, it isn't always practicable
for all users. For example, Emacs together with Emacspeak is my primary
accessible interface. While I could use a browser, it would be severely
inconvenient and frustrating.
I have to admit I also have some concerns here. These may or may not be
well founded. My biggest concern is that we don't seem to have a clear
security model. It feels like we are responding to security threats in a
piecemeal and reactive manner and without any clear model. As a result,
there is a risk we will end up with a complex solution where we don't
fully understand how all the separate pieces interact. This could result
in a complex configuration with a low level of confidence, two of
the worst attributes to have when it comes to security.
> Accidental evaluation of code is a real danger for those who insist on opening links to
> org file directly in emacs or even propose to use org as a kind of browser. I raised the
> security issue in response to passionate messages demanding direct ways to work with org
> files from the web. I decided to remind the context with hope that it would help to
> reevaluate severity of the issue.
>
My concern here is that given the power of link configuration, source
blocks, local variables, .dir-local, evaluated block header code etc, it
is extremely difficult to actually know when code will be executed.
One thing I do feel is a risk is that if we don't get the right balance,
the questions about code evaluation may fall to the level of annoying
noise which people get rid of by simply enabling all code evaluation
without question. Obviously, this would be a very bad security decision,
but as we know from years of experience, users will frequently
prioritise convenience over security. If they are unnecessarily 'nagged'
regarding code evaluation, I suspect this is what will happen (noting
that unnecessary is very subjective).
> I do not have a better proposal, but I think I see movement in a wrong direction.
I'm not sure if I have a better proposal either. I'm not even sure if
this is solely an org issue. It could be that Emacs itself needs a
clearer or better understood and explicit security model. This seems
particularly relevant given the growth in support for downloading,
installing and running code from packages distributed by repositories
with no assessment or vetting of code. I find it quite inconsistent that
when I download and install a new theme, I have to explicitly mark it as
'safe', but I can download a package from melpa, elpa etc with no
additional checks or without having to agree to allow access to whatever
service or data it wants.
I do wonder if it would be a good idea to try and document when org will
evaluate code in org files. This would include not just babel block
evaluation, but also elisp evaluation in table formulas, block header
arguments, file option arguments and possibly other subtle cases. This
may enable us to see if we have the granularity of controls correct or
identify inconsistencies and omissions. This information might then be
useful in defining a security model which could then identify what
controls are actually necessary and how to implement them to provide a
more straight-forward configuration for end users. It could also provide
valuable input into what additional tests may be necessary to ensure
things are working as expected.
next prev parent reply other threads:[~2022-12-15 22:11 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-10 20:28 [PATCH] ob-core: add org-confirm-babel-evaluate-cell custom variable Tom Gillespie
2022-12-11 2:58 ` Max Nikulin
2022-12-11 20:27 ` Tom Gillespie
2022-12-11 20:37 ` Tom Gillespie
2022-12-11 20:46 ` Kyle Meyer
2022-12-11 21:08 ` Tom Gillespie
2022-12-12 10:20 ` Ihor Radchenko
2022-12-13 1:53 ` Tom Gillespie
2022-12-13 9:03 ` Ihor Radchenko
2022-12-13 16:31 ` Max Nikulin
2022-12-13 21:16 ` Tom Gillespie
2022-12-14 16:40 ` Max Nikulin
2022-12-14 18:24 ` Tom Gillespie
2022-12-15 9:18 ` Ihor Radchenko
2022-12-15 9:25 ` Tom Gillespie
2022-12-15 9:57 ` tomas
2022-12-15 9:10 ` Ihor Radchenko
2022-12-15 12:10 ` Max Nikulin
2022-12-15 12:25 ` Ihor Radchenko
2022-12-15 14:46 ` Max Nikulin
2022-12-15 21:08 ` Tim Cross [this message]
2022-12-16 6:07 ` Ihor Radchenko
2022-12-16 7:22 ` Tim Cross
2022-12-18 14:19 ` Ihor Radchenko
2022-12-18 21:37 ` Tim Cross
2022-12-20 0:00 ` Tom Gillespie
2022-12-20 0:06 ` Tom Gillespie
2022-12-25 11:00 ` Ihor Radchenko
2022-12-18 14:12 ` Ihor Radchenko
2022-12-25 11:06 ` Ihor Radchenko
2022-12-29 15:58 ` Bastien Guerry
2022-12-29 16:33 ` Max Nikulin
2022-12-29 16:35 ` Ihor Radchenko
2022-12-30 8:52 ` Bastien
2022-12-30 11:10 ` Max Nikulin
2022-12-30 17:43 ` Tom Gillespie
2022-12-31 13:48 ` Ihor Radchenko
2022-12-31 16:15 ` Tom Gillespie
2023-01-02 8:34 ` [SECURITY] Arbitrary code evaluation security in Org (was: [PATCH] ob-core: add org-confirm-babel-evaluate-cell custom variable) Ihor Radchenko
2023-01-02 10:59 ` [SECURITY] Arbitrary code evaluation security in Org Greg Minshall
2023-01-03 9:52 ` [SECURITY] Tangling can overwrite arbitrary tangling targets, including important user files (was: [SECURITY] Arbitrary code evaluation security in Org) Ihor Radchenko
2023-01-02 19:00 ` [SECURITY] Arbitrary code evaluation security in Org (was: [PATCH] ob-core: add org-confirm-babel-evaluate-cell custom variable) Tim Cross
2023-01-03 11:00 ` Ihor Radchenko
2023-01-07 13:12 ` Ihor Radchenko
2023-01-02 15:13 ` [PATCH] ob-core: add org-confirm-babel-evaluate-cell custom variable Bastien Guerry
2023-01-02 15:17 ` Ihor Radchenko
2023-01-02 15:15 ` Bastien
2022-12-13 4:16 ` Kyle Meyer
2022-12-13 16:15 ` Max Nikulin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86len8uxmu.fsf@gmail.com \
--to=theophilusx@gmail.com \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).