[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Crypto consolidation in debian ?

On Thu, Apr 28, 2011 at 03:09:48PM +0200, Simon Josefsson wrote:
> Roger Leigh <rleigh@codelibre.net> writes:
> > libgcrypt has some horrendous bugs which upstream refuse to fix,
> > for example the broken behaviour relating to setuid binaries
> > discussed previously here, and the hard coded behaviour which
> > makes it unsuitable for use in general programs.  See
> >
> > "libgcrypt brain dead?"
> > 3c5cf5261003081534s5202413dw4d93c80db1a30150@mail.gmail.com
> >
> > Until these major issues are fixed, it's simply unusable.
> It appears to be usable by a lot of projects and people, so that seems
> like an exaggeration.  If I have understood Werner correctly, he
> believes that it is the setuid binaries that are broken and should be
> fixed.

It is usable if your program meets the hardcoded assumptions made in
libgcrypt.  If it does not, it breaks badly.  This is why it's not
*generally* usable, but only in specific cases.

Werner's assertions WRT setuid binaries are plain wrong.  gcrypt
takes it upon itself to drop setuid privs because it makes the
*assumption* that you are setuid solely to use mlock().  What if
you are setuid for some other reason?  In every other case, gcrypt
drops root privs when you might still want them.  And in the case
that gcrypt is used as a side effect of being linked into an NSS
module, it can happen during many glibc calls.  That is totally

Example: schroot is setuid and needs to be setuid to chroot() and
setuid() to the specified user.  If you have a NSS module linked
with gcrypt, a simple getpwent call results in a premature dropping
of root privs, and the program subsequently aborts because it no
longer has the privs to do its job.  gcrypt is entirely responsible
for that breakage by making a broken assumption.  It's not the job
of a *library function* to alter *global process state* as a side

setuid binaries which are setuid solely for mlock() need to drop
root privs themselves, or have some means for them to instruct
gcrypt to drop them explicitly on request.  Doing it by default is
poor practice, and breaks things as that thread shows.  This is a
fundamental design flaw in gcrypt which needs fixing before it is
suitable for general purpose use.


  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.

Attachment: signature.asc
Description: Digital signature

Reply to: