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

Re: Crypto consolidation in debian ?

On Sun, May 01, 2011 at 02:29:39PM +0200, Andreas Metzler wrote:
> Simon Josefsson <simon@josefsson.org> wrote:
> [...]
> > 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.
> [...]
> Hello,
> I would rather say he considers NSS (or PAM) fundamentally broken,
> because a tiny, scrutinized SUID binary ends up with *huge* amounts of
> external unrelated code in its address space after getpwnam().

This is something I can understand to an extent.  Having a single
service providing access to the NSS databases would offer some
advantages.  Unfortunately, I've only ever heard bad things about
nscd.  If we could move to having a central service, rather than
having every process load in a pile of extra libraries, I would
probably be in favour of it.  If would make some things, such as
NSS queries inside chroots, much more efficient and robust.

However... that's not the reality right now, and it never has been.

Even if the NSS situation changes, surely it's immediately obvious
that a random library function should not tamper with the uid of a
process as a side-effect?  Unless the caller explicitly requested
dropping of root privs, no library has *any* business in changing it.
The reality is that only the main program knows what uid and other
privileges it wants and needs to function; a library can't make any
assumptions about what may or may not be appropriate here.  It could
be instructed by the main program to drop privs, but it can't
unilaterally make that decision on its own, which is what libgcrypt is
doing right now.

> Also libgcrypt does seem to be designed to be used indirectly (via
> gnutls) without knowing and caring about it. (Threading, secmem).
> Which is why about 50% of all gnutls-using packages are using
> gcry_control.

This is the root cause, I think.  libgcrypt was developed as part of
gnutls, and although it's a separate library, it's insufficiently
generalised.  It's implicitly doing things the way gnutls wanted them
doing, and rather than making the library completely general and
moving special case logic into the callers (or only doing it upon
specific request), we're in the situation we have now: breakage.
Using it indirectly is not a solution; the solution is to fix the
library to work sensibly by default, and fix up the client code
relying on the assumptions made by the library so that they can be
removed and/or made non-default.


  .''`.  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: