Re: Thoughts on the standardization of Org

[Maxim Nikulin <manikulin@gmail.com>]

> * Maxim Nikulin [2020-11-09 17:06]:
>> 2020-11-08 Jean Louis wrote:
>>> That is right, I am using it since years in ~/.mailcap that works well
>>> for mutt email client.
>>>
>>> text/org;	emacsclient %s; nametemplate=%s.org;
>>> text/x-org;	emacsclient %s; nametemplate=%s.org;
>>
>> Just for curiosity, couldn't it lead to execution of arbitrary code
>> placed into elisp table expressions, some macro, etc.?

My question is solely concerning content of an org file. Let's assume 
default emacs and org mode settings or customization that does not bring 
more weakness.

I consider an attack through content of an org file obtained from 
network. It may be a message from a person even from usual contact list 
whose computer was infected by some malware. Imagine that botnet 
developers would notice new RFC on org mode and would add a plugin 
capable to add specific payload (fetching and launching its agent using 
elisp) if org files noticed in the host owner mailbox. I would not like 
to see org next to office files in security warnings.

The reason why I am afraid to add emacs as a MIME handler for org files 
is the following. Nowadays vim is shipped with disabled (at least by 
default) modeline that was used to specify e.g. tab width for the 
particular file, but it allows to change too much settings. After 
skimming through the org manual, my impression is that org mode allows 
to override a lot of settings through "#+setup:" and other directives. I 
do not have a solid notion related to all possibilities to inject elisp 
code so I am not sure that no elisp code embedded into received file is 
executed during opening of the file without any user action.

Viewing received file I would prefer a restricted mode at least to avoid 
obviously dangerous actions:
- C-c C-c for src blocks
- recalculation of a table field containing elisp expression 
accidentally fired by Tab or C-c
- export (however it would require more keystrokes, so a chance to 
activate it is not so significant)

I could miss some possibilities to activate arbitrary code. Just 
speculations, maybe such options are safe without modification of 
init.el: custom link handlers, dynamic blocks, column view.

Non-emacs viewer might be safer as a MIME handler despite limited 
functionality.

There was a thread concerning "security considerations" section of RFC 
discussing if the similar section of MarkDown document is suitable for 
org. My impression that org is much more complex.

My worries if arbitrary code could be executed during just opening of a 
file are not directly related to standardization. However I do not think 
that argument on low attack probability due to negligible popularity is 
appropriate in the thread with discussion that standardization could 
make org more wide spread.

2020-11-09 22:59, Jean Louis wrote:
> Quoting '%s' is
> recommended. Mailcap has security issues just as file system has.

I was not going to raise such issues. However I agree that in shell it 
is quite easy to use quotes in a wrong way.

> That is why on GNU/Linux and BSD systems and other systems we have
> login with username and passwords and locking screensavers. Those are
> for use. Computers should be protected from malicious access.

I do not see why it is relevant. Joking colleagues and angry students is 
another attack vector. Mail reader and emacs almost certainly have 
privileges to put something to user's autostart. Passwords are not 
involved. What could help is running a dedicated emacs used as MIME 
handler inside a container with restrictive mount and network namespaces.

> For the same reason one shall be cautious of any packages coming from
> various popular package repositories as such are not verified for
> safety issues.

I would prefer to not touch the subject of degree of trust in respect to 
external packages. Let's limit the scope to org "core", maybe even as a 
part of emacs distribution.