| |||||||||||||
GnuPG _is_ setuidGnuPG _is_ setuidPosted Mar 11, 2007 17:51 UTC (Sun) by ekj (guest, #1524)In reply to: GnuPG _is_ setuid by evgeny Parent article: GnuPG signed message spoofing vulnerability True. But the very same users (be they people or mail-programs) that want to verify the integrity of a message using a public key frequently also wants to sign a message using a secret key. True, true, one *could* do the former with a C-library, and the latter by piping to a setuid-executable, but most developers would probably consider the two funcitons related and prefer they both be accesses by the same mechanism.
(Log in to post comments)
GnuPG _is_ setuid Posted Mar 11, 2007 21:40 UTC (Sun) by evgeny (guest, #774) [Link] Well, such functions may have e.g. insecure_ prefix added, and/or put into a separate header file so one makes an educated decision when using them.
In general, though, the locked-to-RAM pages are more or less a fiction. With the VM stuff entering our life, what an OS believes is RAM might actually be a swap in the host. Ditto for software/hardware suspend etc. All in all, I prefer a clean API over a mess with potential marginal extra security through the locked pages (and much less marginal chances of get screwed because of potential bugs in gpg being run setuid). Not to mention that e.g. ssh doesn't use mlock so ... why would one worry about gpg specifically?
GnuPG _is_ setuid Posted Mar 12, 2007 10:34 UTC (Mon) by ekj (guest, #1524) [Link] True. There are good arguments in favour of just dropping whatever trickery requires setuid at the moment, in which case a library is unproblematic. I'm just saying, aslong as you *DO* want memory-locking, you're going to need an external app for atleast those parts. And if so, that external app may aswell do verification too, not only signing.
GnuPG _is_ setuid Posted Mar 16, 2007 12:28 UTC (Fri) by robbe (guest, #16131) [Link] If you use your private key on a remote host (virtual or not) there aremore practical attack vectors. But best practise is to have the private key only on a device in front of you -- in this case leakage to swap is a concern. But suid-to-root is a stupid hack, better solutions are: (a) allow mlock() for non-root users (I had a trivial kernel patch for this ten years ago) (b) no swap (c) encrypted swap (what I use today)
|
|||||||||||||