80:  Are there any security risks in Emacs?

  * the "movemail" incident (No, this is not a risk.)

    In his book "The Cuckoo's Egg," Cliff Stoll describes this in chapter
    4.  The site at LBL had installed the "etc/movemail" program setuid
    root.  (As of version 19, movemail is in your architecture-specific
    directory; type "C-h v exec-directory RET" to see what it is.)  Since
    "movemail" had not been designed for this situation, a security hole
    was created and users could get root privileges.

    "movemail" has since been changed so that even if it is installed
    setuid root this security hole will not be a result.

    We have heard unverified reports that the 1988 Internet worm took
    advantage of this configuration problem.

  * the file-local-variable feature (Yes, a risk, but easy to change.)

    There is an Emacs feature that allows the setting of local values for
    variables when editing a file by including specially formatted text
    near the end of the file.  This feature also includes the ability to
    have arbitrary Emacs Lisp code evaluated when the file is visited.
    Obviously, there is a potential for Trojan horses to exploit this
    feature.

    Emacs 18 allowed this feature by default; users could disable it by
    setting the variable inhibit-local-variables to a non-nil value.

    As of Emacs 19, the opposite is true: Emacs disallows file variable by
    default, and users must explicitly enable them by setting the variable
    enable-local-variables to a non-nil value.

    For more information, see "File Variables" in the on-line manual.

  * synthetic X events (Yes, a risk; use MIT-MAGIC-COOKIE-1 or better.)

    Emacs accepts synthetic X events generated by the SendEvent request as
    though they were regular events.  As a result, if you are using the
    trivial host-based authentication, other users who can open X
    connections to your X workstation can make your Emacs process do
    anything, including run other processes with your privileges.

    The only fix for this is to prevent other users from being able to open
    X connections.  The standard way to prevent this is to use a real
    authentication mechanism, such as MIT-MAGIC-COOKIE-1.  If using the
    "xauth" program has any effect, then you are probably using
    MIT-MAGIC-COOKIE-1.  Your site may be using a superior authentication
    method; ask your system administrator.

    If real authentication is not a possibility, you may be satisfied by
    just allowing hosts access for brief intervals while you start your X
    programs, then removing the access.  This reduces the risk somewhat by
    narrowing the time window when hostile users would have access, but
    DOES NOT ELIMINATE THE RISK.

    On most computers running Unix and X Windows, you enable and disable
    access using the "xhost" command.  To allow all hosts access to your X
    server, use

      xhost +

    at the shell prompt, which (on an HP machine, at least) produces the
    following message:

      access control disabled, clients can connect from any host

    To deny all hosts access to your X server (except those explicitly
    allowed by name), use

      xhost -

    On the test HP computer, this command generated the following message:

      access control enabled, only authorized clients can connect