User: Password:
Subscribe / Log in / New account

GnuPG _is_ setuid

GnuPG _is_ setuid

Posted Mar 8, 2007 22:00 UTC (Thu) by ballombe (subscriber, #9523)
In reply to: GnuPG signed message spoofing vulnerability by kingdon
Parent article: GnuPG signed message spoofing vulnerability

GPGP is setuid to be able to lock memory pages from being swapped to disk.

(Log in to post comments)

GnuPG _is_ setuid

Posted Mar 10, 2007 14:31 UTC (Sat) by evgeny (guest, #774) [Link]

There is no need to worry about memory pages not being swapped to disk when verifying a signed message against a _public_ key...

GnuPG _is_ setuid

Posted Mar 11, 2007 17:51 UTC (Sun) by ekj (guest, #1524) [Link]

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.

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 (subscriber, #16131) [Link]

If you use your private key on a remote host (virtual or not) there are
more 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)

Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds