| |||||||||||||
GnuPG _is_ setuidGnuPG _is_ setuidPosted Mar 11, 2007 21:40 UTC (Sun) by evgeny (guest, #774)In reply to: GnuPG _is_ setuid by ekj Parent article: GnuPG signed message spoofing vulnerability
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?
(Log in to post comments)
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)
|
|||||||||||||