from pinentry-0.7.2.ebuild: 58 for x in curses qt 59 do 60 [ -f ${D}/usr/bin/pinentry-${x} ] && fperms +s /usr/bin/pinentry-${x} 61 done I think the developer meant u+s, this needlessly gives users the ability to read and overwrite files with gid 0 (also, is giving a qt application suid root a great idea? an strace suggests it reads numerous configuration files, i'm sure a local root could be found in this package). # cat secret-file secret $ echo > secret-file -bash: secret-file: Permission denied $ ls -l secret-file -rw-rw---- 1 root root 7 Dec 26 23:57 secret-file $ pinentry-curses OK Your orders please OPTION ttyname=secret-file OK OPTION ttytype=dumb OK GETPIN ^C # cat secret-file ...
swegener please comment/fix.
I added a -r2 with the fperms call fixed. For the general suid problem, I'd like to mention that pinentry drops the privileges very early, directly after locking the memory.
Thx Sven. Should we call for stableization on the -r2 ?
Bah, let's do it. Target KEYWORDS=KEYWORDS="alpha amd64 ia64 ~mips ppc sparc x86"
amd64 stable
sparc stable.
x86 stable
ppc stable
Stable on alpha now. Cheers, Ferdy
Thx everyone. GLSA 200601-01 ia64 should mark stable to benefit from GLSA
Folks, it seems that you did not understand what pinentry is doing. It is designed to make sure that passpharses are entered as securely as possible. For Gtk+ we even wrote a new secure entry widget to make use of non-swappable memory (in gpg parlance "secure memory"). When using Linux the required mlock() will only succeed for euid==0. Thus pinentry allocates the memory right at startup and then drops the privileges. So for extra security it makes actually sense to install it suid(root). However this is not my descision and the same rationale used to install gpg suid(root) should be applied here. If gentoo installs Linux with an encrypted swap, there is no need to install it suid(root) but in other cases one might want to do it. Note, that the whole secure memory business is limited by the IPC mechanism used: The passphrases is eventually passed trough pipe buffers; we expect that they are soon reused and zeroed out.
Hey werner, the bug was that the ebuild incorrectly set the sgid bit, we still install pinentry with the suid bit set. This was a bug in our ebuild, not with pinentry btw :)