From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id IKsjAtsKtGOrqQAAbAwnHQ (envelope-from ) for ; Tue, 03 Jan 2023 12:00:43 +0100 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id gFoZAtsKtGMh8wAAauVa8A (envelope-from ) for ; Tue, 03 Jan 2023 12:00:43 +0100 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 D65991EF40 for ; Tue, 3 Jan 2023 12:00:42 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pCf1H-0001S9-La; Tue, 03 Jan 2023 05:59:47 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pCf1F-0001Rj-Rl for emacs-orgmode@gnu.org; Tue, 03 Jan 2023 05:59:45 -0500 Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pCf1D-0003i8-6y for emacs-orgmode@gnu.org; Tue, 03 Jan 2023 05:59:45 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 2E400240190 for ; Tue, 3 Jan 2023 11:59:41 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1672743581; bh=XyDgIRDLXWeGpAj7ZeqmgBgipKjwf3n7AqvPJaAJ30U=; h=From:To:Cc:Subject:Date:From; b=a0muacAQgapj/MVRO4PUxDMWU7N852qB2kHd979Zytx0YUeBjzHEvRUmx9hwvswcb oFavUndP3OnmaqFW6d1HqBsIGiawZumoF21vXhxOLa9y2bsQ9lOvKW8bJqw54+yZKe UUYVe7AdGti5Mw/uoFk3H1WxB1zco2O0fINiDTr30Co20PxMoVvXN+D6/Tk6rsgVCh XAEfU4HBroYcINmV7wxP8syP8Sv9vQuhzgpn01Rk0dFJnzzn1SwIIuw+JfiayhcigZ ugPPSt5zavv1T49UTf/u6bNFHNWODKl1TYrA0dXWnZGLw9xk/sKl4IgOEa14HfU5BT Co5mGgTWmLh8Q== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4NmV9m20J3z6tmN; Tue, 3 Jan 2023 11:59:40 +0100 (CET) From: Ihor Radchenko To: Tim Cross Cc: emacs-orgmode@gnu.org Subject: Re: [SECURITY] Arbitrary code evaluation security in Org (was: [PATCH] ob-core: add org-confirm-babel-evaluate-cell custom variable) In-Reply-To: <86tu18d811.fsf@gmail.com> References: <87359ld5ye.fsf@kyleam.com> <874ju0j538.fsf@localhost> <87k02fspxa.fsf@localhost> <87edsii4mo.fsf@gnu.org> <87h6xetbfn.fsf@localhost> <878rips273.fsf@bzg.fr> <878rinadlq.fsf@localhost> <87edsd5o89.fsf@localhost> <86tu18d811.fsf@gmail.com> Date: Tue, 03 Jan 2023 11:00:09 +0000 Message-ID: <87358rkhmu.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=185.67.36.65; envelope-from=yantar92@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: emacs-orgmode-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN ARC-Seal: i=1; s=key1; d=yhetil.org; t=1672743642; a=rsa-sha256; cv=none; b=VwfLHbpsmS5RJonmUrthknApCiNghHcaQhFeEV+WL2hD8C8IOvj4YjsZhUXqRnOZykZMaV mvAXHCcoEahUnsQRRi3WVbbRKCdjqm4pHFW48RRpL4c6xuiN8yBMgUz/otG7kBrZEqSxoc iIqpexyjFvI6yR8OiQ26Me3Y2UMewEivAF8ZpNRnfQismynUlWXSC/nRgozP8IU2lnOIp3 aje5dZjtMbM7xeSqRwibeyTWEyPUkI0fgFmIvTM3UQTy5uVbrq76G6Z4iTO/Z/0pu7dVax HBd7ViH2s58vgcDFcuni7GSZ9YLWlgtnxvs0tL3fbCol4VNQb/2OFbTYyl65+w== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=a0muacAQ; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=posteo.net ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1672743642; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=5PEK6NdMQH5mMs6rrt8HUK0RdwVkbIZ0nXMTGW8+MmM=; b=ozYQZk9LAHRzNS14vkYGEgw6HQorgiYfxOB1muH5OLN6TCfoFd5yEY/apTyoOva7jZy+Ar minnNk5Vl0DI+d6ZrEqu1KpZGhkQIhXwyWoubM9tmwCMcXZeIaimwHaiyB1oM8gdCCPl22 H7Q8p++goQVadJFLXD5lanwGon3TBqBS1CA1Nb8JZgY9SrZRfDrz/GBTulxdzxicbWYEdQ Q0Ms3CWHahfwzccHaDMUE5zfoewh3XmKd2+mh7m/7kShX7j3nSLNb7Q3aAO+5w70399b+7 vc4qc3YHVsEgmUsC6nIkYLMq/RK66s8Xrl3ctNuoD5YHqFxS1nHc1SVnGWStEA== X-Spam-Score: -11.30 X-Migadu-Queue-Id: D65991EF40 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=a0muacAQ; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=posteo.net X-Migadu-Scanner: scn0.migadu.com X-Migadu-Spam-Score: -11.30 X-TUID: 2v+kjN4P2jWA Tim Cross writes: >> 1. Introduce a new customization `org-confirm-evaluate-safe-regexps' >> listing regexps that are considered safe or cons cells >> (src-body/header-arg/table/macro/diary . regexp) >> >> 2. Introduce a new customization `org-confirm-evaluate' that can be set >> to t/nil/prompt/safe/[function]/[alist]: >> - t/safe :: to display default prompt unless the code block in buffer is >> marked safe >> - prompt :: always ask (the prompt will then not display options to >> add current sexp to safe list) >> - [function] :: custom function that returns t/safe/prompt/[alist] >> - [alist] :: (src-body/header-arg/table/macro/diary/t . >> t/safe/prompt/function) >> (t . ) stands for default value. >> >> 3. The default prompt will mimic `org--confirm-resource-safe', >> additionally accepting Y/N to accept/decline all the evaluation in >> current command. >> >> This system will be used across Org for code evaluation. Old variables >> will be supported, but obsoleted. >> >> WDYT? > > For many users who don't share org files, who work on a single user > desktop and who implicitly trust the files they are working with, it is > unlikely they want to be bothered by any of this. It should 'just > work'. I suspect this is the majority. Others will have some sharing of > documents - perhaps in a work group, a class or some form of team > activity. The trust here is likely fairly high but perhaps not > absolute. There is probably a need for some choice on execution on a per > file basis. Finally, there are those org files which are from unknown > and therefore untrusted sources - email messages, cloned git > repositories, Emacs packages, etc. Most people likely don't want these > executed by default and want to be asked or be able to block by default. > The point is, we probably need to consider not only what variables are > required, but also some infrastructure for managing those variables > based on some form of document classification or trust. You touch on > this with some of what has been outlined, but it focuses on the original > data source. That information can be lost once a file has been > retrieved. However, the trust level of that file likely doesn't change > just because it now resides 'locally'. Oops. I think I forgot to describe another point I was thinking about. REGEXP in `org-confirm-evaluate-safe-regexps' may also be a cons cell (SOURCE . REGEXP). SOURCE can be a file path, a directory containing the file, or file contents hash. This way, we can mark whole files or directories as safe. Or just specific code blocks in files or directories. > I do wonder if the idea of a document classification model and some form > of heuristic algorithms to handle default document classification might > be useful. I do not think that we need to go in this direction. I doubt that we are qualified to get the heuristics right. Such things should either be maintained in Emacs core or not provided at all to not create false sense of security. Look at Emacs' approach to file-local variables. There are no heuristics there. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at