From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id KN90H9f+ql/9EwAA0tVLHw (envelope-from ) for ; Tue, 10 Nov 2020 20:57:59 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id EPdfG9f+ql9KcQAA1q6Kng (envelope-from ) for ; Tue, 10 Nov 2020 20:57:59 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id DE3FE9402DD for ; Tue, 10 Nov 2020 20:57:58 +0000 (UTC) Received: from localhost ([::1]:50262 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kcaiD-0005Ps-Ov for larch@yhetil.org; Tue, 10 Nov 2020 15:57:57 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:45012) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kcahe-0005PV-Jz for emacs-orgmode@gnu.org; Tue, 10 Nov 2020 15:57:22 -0500 Received: from static.rcdrun.com ([95.85.24.50]:58221) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kcahc-00034O-BS for emacs-orgmode@gnu.org; Tue, 10 Nov 2020 15:57:22 -0500 Received: from localhost ([::ffff:197.157.34.177]) (AUTH: PLAIN admin, TLS: TLS1.2,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by static.rcdrun.com with ESMTPSA id 00000000002C0005.000000005FAAFEAF.000019A5; Tue, 10 Nov 2020 20:57:18 +0000 Date: Tue, 10 Nov 2020 23:22:35 +0300 From: Jean Louis To: Maxim Nikulin Subject: Re: Thoughts on the standardization of Org Message-ID: References: <20201101161317.GA6609@maokai> <87imaoekrz.fsf@web.de> <39fb1f8d-4407-9359-ad14-72ae7841fda9@grinta.net> <87tuu85djy.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/2.0 (3d08634) (2020-11-07) Received-SPF: pass client-ip=95.85.24.50; envelope-from=bugs@gnu.support; helo=static.rcdrun.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/11/10 14:03:25 X-ACL-Warn: Detected OS = Linux 3.11 and newer [fuzzy] X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: emacs-orgmode@gnu.org Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Scanner: ns3122888.ip-94-23-21.eu Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Spam-Score: -1.01 X-TUID: myTsJG1tpzkc * Maxim Nikulin [2020-11-10 19:22]: > > * 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. Quite understandable and I appreciate your awareness on safe computing. That question is solved when there is clear answer if anything gets executed automatically from #+SETUP line when opening an Org file. ‘#+SETUPFILE: file’ The setup file or a URL pointing to such file is for additional in-buffer settings. Org loads this file and parses it for any settings in it only when Org opens the main file. If URL is specified, the contents are downloaded and stored in a temporary file cache. ‘C-c C-c’ on the settings line parses and loads the file, and also resets the temporary file cache. Org also parses and loads the document during normal exporting process. Org parses the contents of this document as if it was included in the buffer. It can be another Org file. To visit the file—not a URL—use ‘C-c '’ while point is on the line with the file name. I have tried to execute file by using: #+SETUPFILE: ~/tmp/message-me.el in Org file and: message-me.el: (message "I have been executed.") But I did not see message executing. > Viewing received file I would prefer a restricted mode at least to avoid > obviously dangerous actions: > - C-c C-c for src blocks See file local variables in manual. They can also be dangerous and unsafe. Emacs is environment with programming language and executing many things is possible when user desires so. Safety of files should be decided from viewpoint of what Emacs does by default Question is if anything would be executed by default when Org file is opening? > 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. As activating any code is not by default and is left to user, there is no need to prevent that generally. You are aware that it can be executed if you invoke some key presses, so you can control it by not invoking it or by inspecting it before invoking it. > 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. Org is much more complex. Of course there are ways how some markdown implementations could execute external programs. Markdown is meant to create HTML. It was not meant originally to share information directly in Markdown and yet people do it. We just need to make sure that nothing by default executes when any Org file is opened and that is it. > 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. Emacs allows any file-local-variables in any type of a document. Then it asks user if user would like to accept such variables or not: Hypothetical and untested example: > Local Variables: > compile-command: "rm -rf ~/*" > End: Many users may not know what "rm -rf ~/*" mean and would say Y. Automated or hidden attack on many users could be initiated by implementing a shiny theme, making it popular and having few banal variables to be accepted, and later introducing change that: captures users' private information, passwords, contact address book for spamming or similar. rm -rf would be too obvious. It could download backdoor shell and have attacker browse files. > 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. chroot, jails (BSD), or running program over shell in other user space could be possibilites. See example how DragonflyBSD author recommends how to run browser safely: How to Run a More Secure Browser https://www.dragonflybsd.org/docs/handbook/RunSecureBrowser/ > > 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. I am getting you fully.