On Tue, Dec 06 2016, Jacob Bachmeyer wrote:
(Or we could just randomize per-user and dump Emacs the first time it
runs for a particular user? If we do that after loading ~/.emacs, we
also improve people's startup time. Invalidating and regenerating the
dump when configuration changes would be a challenge though.)
That should not be too difficult, if you can track which files were
read when creating the dump and store some fields from the stat(2)
information on those files in the dump. I am using this approach in a
packaging system that I am developing to close a race between
attaching a file to an archive handle and actually writing the
archive, at which time the digest of the file is computed. (I wanted
to avoid reading input files twice.)
I take a conservative approach and verify that the
st_{ino,dev,size,blocks,{m,c}tim{e,.tv_nsec}} fields are all
unchanged. For my use, writing the archive produces a hard failure if
this check fails; for Emacs, failing that check would indicate "time
to rebuild the fast-load cache".
On the other hand, I think that per-user dumps are a bad idea--the
Emacs dump is an inscrutable binary blob
Users run lots of inscrutable binary blobs. At least this one is made
from free software. ("Sure", you might think, "we can just have the
system Emacs *sign* the blob." But an attacker could just read the
private key right out of the Emacs binary. You really can't win.)
and therefore a good place
for an intruder to hide persistent nastiness. This could allow an
intruder to add a back door to a user's Emacs in a difficult-to-detect
manner while needing only temporary access to that user's account,
say, from exploiting any program that user runs.
I don't think attempting to defend against this sort of attack, at least
the way you suggest, is desirable. An attacker who can modify user
files like that has already won --- there are all sorts of user-mode
"rootkits" that hide themselves very effectively.
https://blogs.msdn.microsoft.com/oldnewthing/20060508-22/?p=31283