security model

Robert J. Hansen rjh at sixdemonbag.org
Sun Jul 13 00:41:32 CEST 2025


> Either you plan much farther ahead than the common cybercrook or we are 
> talking about targeted attacks instead of the much common "spam" 
> attacks.  (That said, GnuPG is *supposed* to stand up against targeted 
> attacks.)

Correct, I'm talking about targeted attacks. Random drive-bys are not of 
much personal or professional concern. This is of course my risk model, 
and I don't expect it to be relevant to anyone else. :)

> The catch is that the "juicy" stuff is typically *in* the user's account 
> on a single-user box... and therefore accessible without elevation if 
> Mallory is hitting the client.

If it's a single-user box, sure. Of course, many single-user boxes make 
privilege escalation ridiculously easy, so why not? (Everyone who has 
put NOPASSWD: ALL into their sudoers file, please raise your hands...)

> Why risk the exposure (and correction) of a privilege escalation exploit 
> when everything Mallory wants is right there without it?

Because even on single-user boxes, persistence and cleaning up one's 
tracks is much easier done with escalation than without. If persistence 
and concealment is part of the attack profile, you need escalation.

> In my model, Mallory's ideal goal is make off with your data and/or 
> private keys and/or an unauthorized signature without leaving a trace 
> aside from possible intentional tampering.

Then Mallory needs escalation. If you're going to do things like look 
through the system logs and scrub them appropriately, you need to escalate.

This is why I believe a competent Mallory always escalates. It's simply 
not possible to do a thorough cleanup job without escalation.

> In that environment, a smartcard is not sufficient; you need an isolated 
> box.

Frankly, I think you need a lot more than a smartcard, too, starting 
with a radical rethink of "why am I hosting such valuable files on a 
machine connected to the internet?"  :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20250712/f18d06d3/attachment-0001.sig>


More information about the Gnupg-devel mailing list