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; See File Local Variables.
Similarly, a directory can specify local variable values common to all
files in that directory; See 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,
- 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. See 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)’. See Read Only Buffers.
- Emacs has several functions that deal with passwords, e.g.,
read-passwd. See 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. See 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
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
shell-quote-argument quotes shell metacharacters but
not leading ‘-’. See Shell Arguments. Typically it is safer
call-process than a subshell. See Synchronous Processes. And it is safer yet to use builtin Emacs functions; for
" t) instead of
invoking mv. See Changing Files.
- Coding systems
- Emacs attempts to infer the coding systems of the files and network
connections it accesses. See 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. See 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. See System Environment.
Emacs has customization and other variables with similar
considerations. For example, if the variable
specifies a shell with nonstandard behavior, an Emacs-based
application may misbehave.
- 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
nil, file names using a certain
syntax are interpreted as being network files, and are retrieved
across the network. See The Tramp Manual.
- 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.
See 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.