elisp: Security Considerations
38.22 Security Considerations
=============================
Like any application, Emacs can be run in a secure environment, where
the operating system enforces rules about access and the like. With
some care, Emacs-based applications can also be part of a security
perimeter that checks such rules. Although the default settings for
Emacs work well for a typical software development environment, they may
require adjustment in environments containing untrusted users that may
include attackers. Here is a compendium of security issues that may be
helpful if you are developing such applications. It is by no means
complete; it is intended to give you an idea of the security issues
involved, rather than to be a security checklist.
File local variables
A file that Emacs visits can contain variable settings that affects
the buffer visiting that file; File Local Variables.
Similarly, a directory can specify local variable values common to
all files in that directory; Directory Local Variables.
Although Emacs takes some effort to protect against misuse of these
variables, a security hole can be created merely by a package
setting ‘safe-local-variable’ too optimistically, a problem that is
all too common. To disable this feature for both files and
directories, set ‘enable-local-variables’ to ‘nil’.
Access control
Although Emacs normally respects access permissions of the
underlying operating system, in some cases it handles accesses
specially. For example, file names can have handlers that treat
the files specially, with their own access checking. Magic
File Names. Also, a buffer can be read-only even if the
corresponding file is writeable, and vice versa, which can result
in messages such as ‘File passwd is write-protected; try to save
anyway? (yes or no)’. Read Only Buffers.
Authentication
Emacs has several functions that deal with passwords, e.g.,
‘read-passwd’. Reading a Password. Although these
functions do not attempt to broadcast passwords to the world, their
implementations are not proof against determined attackers with
access to Emacs internals. For example, even if Elisp code uses
‘clear-string’ to scrub a password from its memory after using it,
remnants of the password may still reside in the garbage-collected
free list. Modifying Strings.
Code injection
Emacs can send commands to many other applications, and
applications should take care that strings sent as operands of
these commands are not misinterpreted as directives. For example,
when using a shell command to rename a file A to B, do not simply
use the string ‘mv A B’, because either file name might start with
‘-’, or might contain shell metacharacters like ‘;’. Although
functions like ‘shell-quote-argument’ can help avoid this sort of
problem, they are not panaceas; for example, on a POSIX platform
‘shell-quote-argument’ quotes shell metacharacters but not leading
‘-’. Shell Arguments. Typically it is safer to use
‘call-process’ than a subshell. Synchronous Processes.
And it is safer yet to use builtin Emacs functions; for example,
use ‘(rename-file "A" "B" t)’ instead of invoking ‘mv’.
Changing Files.
Coding systems
Emacs attempts to infer the coding systems of the files and network
connections it accesses. Coding Systems. If Emacs infers
incorrectly, or if the other parties to the network connection
disagree with Emacs’s inferences, the resulting system could be
unreliable. Also, even when it infers correctly, Emacs often can
use bytes that other programs cannot. For example, although to
Emacs the null byte is just a character like any other, many other
applications treat it as a string terminator and mishandle strings
or files containing null bytes.
Environment and configuration variables
POSIX specifies several environment variables that can affect how
Emacs behaves. Any environment variable whose name consists
entirely of uppercase ASCII letters, digits, and the underscore may
affect the internal behavior of Emacs. Emacs uses several such
variables, e.g., ‘EMACSLOADPATH’. Library Search. On some
platforms some environment variables (e.g., ‘PATH’,
‘POSIXLY_CORRECT’, ‘SHELL’, ‘TMPDIR’) need to have
properly-configured values in order to get standard behavior for
any utility Emacs might invoke. Even seemingly-benign variables
like ‘TZ’ may have security implications. System
Environment.
Emacs has customization and other variables with similar
considerations. For example, if the variable ‘shell-file-name’
specifies a shell with nonstandard behavior, an Emacs-based
application may misbehave.
Installation
When Emacs is installed, if the installation directory hierarchy
can be modified by untrusted users, the application cannot be
trusted. This applies also to the directory hierarchies of the
programs that Emacs uses, and of the files that Emacs reads and
writes.
Network access
Emacs often accesses the network, and you may want to configure it
to avoid network accesses that it would normally do. For example,
unless you set ‘tramp-mode’ to ‘nil’, file names using a certain
syntax are interpreted as being network files, and are retrieved
across the network. The Tramp Manual (tramp)Top.
Race conditions
Emacs applications have the same sort of race-condition issues that
other applications do. For example, even when ‘(file-readable-p
"foo.txt")’ returns ‘t’, it could be that ‘foo.txt’ is unreadable
because some other program changed the file’s permissions between
the call to ‘file-readable-p’ and now. Testing
Accessibility.
Resource limits
When Emacs exhausts memory or other operating system resources, its
behavior can be less reliable, in that computations that ordinarily
run to completion may abort back to the top level. This may cause
Emacs to neglect operations that it normally would have done.