Re: Preview: portable dumper

[Jacob Bachmeyer]

Daniel Colascione wrote:
> On Tue, Dec 06 2016, Jacob Bachmeyer wrote:
>   
> > Daniel Colascione wrote:
> >     
> > > 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.)
> > >   
> > >       
> > "A strange game.  The only winning move is not to play."
> >
> > The system Emacs dump cannot be modified by a user's account.
> > A per-user dump could be.  Currently, this particular persistence
> > option for a (user-level) intruder does not exist; I argue that we
> > should think very carefully before creating it.  (No objection to
> > using this for the system Emacs dump, though.)
> >     
>
> And you don't have any binaries under $HOME? No elc files? No
> .pyc files? Really? Are you sure that you can read a pyc file and
> detect exploit code?
>   

A multi-user secure environment may forbid binaries in $HOME entirely 
and mount /home noexec.

> > A counter-proposal to signing the dump:  upon loading the dump,
> > display a digest or randomart-like image that summarizes the dump.
> > Users who care can then notice if the dump changes when it should not.
> >     
>
> That'll annoy users, and I've never seen a real human being pay
> attention to those SSH key fingerprint ASCII art things, much less some
> weird art thing that Emacs might display on startup.
>   

It is sad how many people just do not care.  Then they complain when 
told that their email account is sending spam.

Back to the topic, how would this annoy users?  Put it in the splash 
screen with other details like the Emacs version that the willfully 
ignorant will ignore.
"This is GNU Emacs <version> (<platform>) of <date> on <system> using 
image <digest of loaded dump>"

> > > > 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
> > >   
> > >       
> > Some of the comments on that blog are appropriate here.  This kind of
> > "not a security problem because <insert excuse here>" is a position
> > for which Microsoft is infamous.
> >     
>
> That the author of that post works for Microsoft is irrelevant.
>
> "Security" is a meaningless word.  You need to be secure *against*
> something.  You need a threat model.  Your threat model is an attacker
> who already has the ability to overwrite files under $HOME.  Such an
> attacker can do anything anyway (e.g., LD_PRELOAD something in
> ~/.profile that presents whatever secure fantasy the attacker wants to
> present), so your proposed security measure doesn't actually help ---
> and it has costs.
>   

Modifying .profile is riskier for the attacker than modifying a binary 
dump.  A system backup facility, for example, will notice that the 
user's .profile has changed and will probably store the diff.  A 
security policy may have a system daemon scanning user .profiles for 
references to LD_PRELOAD.

> Sorry: I don't think that forgoing user dumps on security grounds makes
> any sense.  There might be plenty of other reasons not to implement the
> feature, but security isn't one of them.
>
> That's not "an excuse" --- as if implementing any random feature
> somebody proposes in the name of "security" is some moral imperative, we
> need to be excused from our duty to perform it --- it's reason.
>   

I did not say that we absolutely should not have per-user dumps, only 
that we should consider the risks that they introduce.  At the least, 
there should be an option to not use per-user dumps.  This would be very 
little of a problem, since the portable dump mechanism will allow for 
dumps to be incrementally built.  This will enable a user dump to be 
built/updated by loading the system dump, processing .emacs (or some 
special user loadup file if the user does not want .emacs in the dump) 
and saving a new dump file.  Or for user dumps to be unused, and we stay 
right where we are now on those systems, but without depending on the 
internals of libc.

> > The issue that I see is that a
> > per-user Emacs dump (which of course must be writable by the user) is
> > a place (platform-independent, even!) where an attacker can hide a bit
> > of code to make future access easier, even after the exploit that
> > initially allowed the attacker to get in is fixed.
> >     
>
> System compromises are never "fixed": there are too many places for
> attackers to hide code.  If your account has been compromised, you lose.
> Restore from backup.
>   

This comes back to an attacker "winning the battle and losing the 
war"--if you do not know your account has been compromised, then you do 
not know that you should be restoring from backup--and the attacker 
"wins the war".  Non-persistent "smash-and-grab" attacks have an 
important advantage for the attacker in this sense.  That integrity in 
Free environments is currently a mess is no reason to charge ahead 
without considering what effects our efforts will have on the situation.



I had meant to suggest a solution to the problem of invalidating a user 
dump/fast-load cache; I have been surprised that the discussion has been 
more about an offhand remark expressing uncertainty about the wisdom of 
per-user dump files.

To be clear:  I am in favor of supporting per-user dumps, but vehemently 
opposed to forcing their use.  If nothing else { alias emacs='emacs 
--load-dump=~/.emacs.pdmp'; } will provide support for per-user dumps 
whether or not Emacs itself checks for one.


-- Jacob