From: Tim Cross <theophilusx@gmail.com>
To: Ihor Radchenko <yantar92@posteo.net>
Cc: emacs-orgmode@gnu.org
Subject: Re: [PATCH] ob-core: add org-confirm-babel-evaluate-cell custom variable
Date: Mon, 19 Dec 2022 08:37:08 +1100 [thread overview]
Message-ID: <86tu1sidg6.fsf@gmail.com> (raw)
In-Reply-To: <87k02o6bgv.fsf@localhost>
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.
next prev parent reply other threads:[~2022-12-18 21:56 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
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 [this message]
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=86tu1sidg6.fsf@gmail.com \
--to=theophilusx@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=yantar92@posteo.net \
/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).