Re: Preview: portable dumper

[Daniel Colascione <dancol@dancol.org>]

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