Interestingly, as I was looking through my notes in
orgstrap, I see my past self had found a macro
org-babel-one-header-arg-safe-p which pointed to
defconst org-babel-safe-header-args, but that is
a const and not really user configurable. Of course
the user could cl-setf on it, but it also only checks
strings and has no ability to e.g. see if the value of
(symbol-function #'identity) has changed since the
check function was defined. Two examples.
(let ((old-identity (symbol-function #'identity)))
(cl-letf* (((symbol-function #'identity)
(lambda (x) (message "there") x)))
(identity 'hello)
(equal (symbol-function #'identity) old-identity)))
(let ((old-and (symbol-function #'and)))
(cl-letf* (((symbol-function #'old-andf) old-and)
((symbol-function #'and)
(lambda (&rest args)
(message "oops %s" args)
(old-andf args))))
(list
(and)
(and 1 2 3)
(equal (symbol-function #'and) old-and))))
> Tom, does not the following allow to achieve the same without your patch?
It works if I have a closed set of things I want to allow but not if I
want to set it to nil to e.g. restore the old behavior (worse for
security but not as bad as setting ocbe to nil), e.g. if I'm
under duress and need to get something that used to work to
work again without the risk of automatically running dangerous
code, (e.g. blocks that might rm something).
> I know, it does not work, but I think it is due to (format "%S" cell)
> instead of passing cell directly in
>
> - '((:eval . yes)) nil (format "%S" cell)
>
> My point is that if some expression is safe for a variable value then it
> is safe for the source block body.
There is another use case here, which I alluded to in the previous
comment, which is that sometimes ocbe is the last line of defense
against running dangerous code. Ideally users would have set
:eval never on blocks like that to be sure, but if they don't you
don't want someone already trying to get something to work
to get too much to work.
Again, this is focused on the ocbec -> nil case.
> Have you ever seen the prompt for a table?
Err ... maybe? So the answer is probably no.
> I suppose, tables are the most prominent security issue related to
> unsolicited code execution:
For me it would be arbitrary expressions in the headers
of source blocks. Hard to know which one is more prevalent
across the population of org users.
> Max Nikulin to emacs-orgmode. Re: [BUG][Security] begin_src :var
> evaluated before the prompt to confirm execution. Fri, 28 Oct 2022
> 11:11:18 +0700. https://list.orgmode.org/tjfkp7$ggm$1...@ciao.gmane.io
>
> I am still in doubts if
>
> 10e857d42 2022-10-28 11:09:50 +0800 Ihor Radchenko: org-babel-read: Obey
> `org-confirm-babel-evaluate'
>
> was an unambiguous improvement. Perhaps it just forces more users to set
> `org-confirm-babel-evaluate' to nil compromising their security to more
> severe degree.
Heh. It is always a hard balance to strike. In the context of that
thread having a variable that would find-file-literally for untrusted
org files by default might be useful.
Again, it is a pain. I can tell you from experience having written
the system that does something similar for orgstrap. There is
no safe way other than a user-maintained whitelist based on
file hashes, everything else can be spoofed in one way or another.
I suspect that once we have the machinery in this patch in
place we can look for some sane defaults. Note that the example
function we keep passing around isn't quite good enough because
someone could probably figure out how to rewrite the identity
function so we would need to make sure that it had not changed
since emacs was loaded (unlikely, but if I can image it someone
could surely do it).
