emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bug#58774: 29.0.50; [WISH]: Let us make EWW browse WWW Org files cor


From: Tim Cross
Subject: Re: bug#58774: 29.0.50; [WISH]: Let us make EWW browse WWW Org files correctly
Date: Thu, 27 Oct 2022 08:41:13 +1100
User-agent: mu4e 1.9.1; emacs 29.0.50

"Dr. Arne Babenhauserheide" <arne_bab@web.de> writes:

> [[PGP Signed Part:Undecided]]
>
> Ihor Radchenko <yantar92@posteo.net> writes:
>
>> If necessary, we can introduce a special variable in Org mode that will
>> disable all the potential third-party code evaluation, even if user has
>> customized Org to execute code without prompt.
>
> If that would be part of org-mode, this would be close to a
> safe-org-mode.
>
> An important part in what I wrote about safe-org-mode is that it has to
> ensure that what is shown cannot trick the user into thinking something
> else would get run.
>
> A way to reduce risk would be to introduce a domain-allow-list (or
> prefix-allow-list) in eww for filetypes that could be unsafe, so you
> could for example add "orgmode.org" to your allowlist and for those
> domains org-files would auto-open in org-mode.
>
> Such security risks have a tendency of getting weaponized down the road
> when they really hurt. Like when people didn’t care about npm
> dependencies and had them suddenly deleting their files. And opening in
> the currently used Emacs may give a malicious file access to remote
> files opened via tramp, even if you (by virtue of being careful) require
> a password for the connection to sensitive servers. That way, running
> something in Emacs can be even more dangerous than running it in the
> shell.
>

and people constantly use M-x package-install to install packages
from GNU ELPA, nonGNU ELPA and MELPA, often with this misguided belief
that these packages are being vetted by the security fairies. 

As was seen after the openssl security failures, just because lots of
people use something and just because lots of people may work on and
look at the code, it is no guarantee the code is secure or has no
malicious content. Our systems have become far too complex for such ad
hoc processes providing any assurance. Likewise, as has been shown with
NPM and various browser 'extension stores', packages which were once
trustworthy can easily become owned/developed by new parties with less
ability or are less trustworthy. 

While adding the sorts of controls you outline is not a bad idea, I
think it is far more important to train people to accept that their
system simply is not secure. You should start from the position that
Emacs is not secure. Why? Because it is a large, complex and powerful
piece of software which has no formal security analysis or testing and
is usually augmented with numerous packages of unknown quality from
largely unknown sources. Essentially, Emacs already suffers from all the
same issues identified for systems like node and the NPM ecosystem. 

The only think which is really providing protection for us Emacs users
is that the rewards for compromising Emacs are too low for the effort
required. Similar to why you don't see many viruses on macOS - it isn't
that it is significantly more secure than Windows (these days), but
rather the pool of potential 'targets' and scale of rewards are higher
when you focus on the Windows environment. It is all about return on investment.

Security is a huge challenge for open source. The effort and resources
required to constantly analyse and test projects for security issues is
too high for most medium to large projects. The fact many open source
projects also rely on other open source projects for various libraries
etc also means that in addition to worrying about the security of the
code in a project, the project also has to worry about 'supply chain'
security i.e. ensure the external project dependencies are also secure
and securely managed.

So what do we do? In the famous words of Douglas Adams "Don't Panic!

Rather than worry if some package or change will make Emacs less secure,
assume it already is insecure and then examine how you use it and
consider both the likelihood of being compromised and the impact when
that occurs. This will differ depending on who you are and what you
do. For example, if your a researcher working in a field where your
research has high commercial value or a journalist working in countries
with a poor human rights history and government parties may want to
compromise your sources etc, both the likelihood and consequences could
be high and you may need to take additional measures or modify how you
use emacs (e.g. only use packages you have reviewed and tested and only
update after formal review and testing of updated version, don't use
Emacs for email or web browsing, only run emacs in an isolated locked
down container etc). On the other hand, if your just a keen hobbyist,
the likelihood and consequences of a security breach are both likely low
and you may decide adding additional packages is an acceptable risk.
Even if you decide your risks are low, you may still decide to not use
Emacs for some purposes. For example, you might decide not to use Emacs
for password management or not use Emacs packages which require you to
keep sensitive data (toekns, passwords, API keys etc) using insecure
mechanisms etc. Keep in mind that convenience and complexity are often
the two biggest threats to security.  Assess risks within
your own personal context as what is appropriate for one person may not
be for another.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]