[Cryptography] where shall we put the random-seed?

[Kevin W. Wall]

On Wed, Jan 3, 2017 at 6:44 PM, Theodore Ts'o <tytso at mit.edu> wrote:
> On Wed, Jan 04, 2017 at 07:26:51PM +0000, Jason Cooper wrote:
>>
>> Ok, I see what you were after.  The random-seed may be no-credit, but
>> once it's been saved with entropy pool >128 bits, then the system is no
>> longer in a bad state.  I can buy that.
>>
>> While pondering this, I hit on a slightly different idea.  Right now,
>> the init scripts save the seed at boot up regardless of amount of
>> entropy gathered.  This is in case of unclean shutdown.
>>
>> Why not trigger a KOBJ_UEVENT_CHANGE when the entropy crosses a given
>> threshold?  Userspace can save to random-seed then.
>
> We can do that, but we want to rewrite the random file right after we
> use it anyway.  The reason is to deny attackers who manage to penetrate root
> from have access to the state of the random used to initialize the
> pool.  It's a minor point, since it only really helps in the case
> where the privilege escalation attack happens soon after the boot
> (when access to the data dumpted into the pool might help), but
> rewriting the random state file is cheap.

Ted,

Pardon my ignorance of your complete threat model here, but if an attacker
manages to gain root access during this stage, is it not already game over?
(Well maybe not if using SELinux and suitable policies, but otherwise, it
sure seems like it is.)

Even if the privilege escalation to root does happen right after boot and
you have rewritten the random state file before whenever, full root access
means any keys generated and on the file system can be read by the attacker,
right? I mean the the attacker can steal any of the generated ssh private
keys in /etc/ssh/ssh_host_*_key, etc. If no one has yet ssh'd into this
server, they could even replace the ssh keys since ssh uses a TOFU model.
The attacker can also read /dev/mem directly or grab the memory of a
particular process in many different ways to later look for encryption keys
or other secrets.

So, I guess I don't understand your threat model here. This seems like
some rare edge case. Once an attacker gets root access, you pretty much
have to figure that they will have that access for an extended period
and unless you have castrated what root can do via SELinux or similar.
I've seem demonstrations of this, e.g., Russ Coker's server, see
http://www.coker.com.au/selinux/play.html for details, but I've yet
to see any IT shops even use SELinux. I'm sure there are some and
a few might even restrict the type of access that root has, but that
seems rare. Is this what you have in mind for your implicit threat
model? If not, could you please elaborate as otherwise, I must be
missing something. But with standard DAC alone, it seems like it is
already game over if an attacker manages local root access even if you
do manage to rewrite the random state file before that attacker gains
root access.

Thanks for helping me understand,
-kevin
-- 
Blog: http://off-the-wall-security.blogspot.com/    | Twitter: @KevinWWall
NSA: All your crypto bit are belong to us.