FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 04-28-2011, 01:09 PM
Simon Josefsson
 
Default Crypto consolidation in debian ?

Roger Leigh <rleigh@codelibre.net> writes:

> On Wed, Apr 27, 2011 at 09:30:05AM -0700, Russ Allbery wrote:
>> Bastien ROUCARIES <roucaries.bastien@gmail.com> writes:
>>
>> >> Patches to WebAuth to support NSS are welcome, but I'm sure not going to
>> >> bother. *Seems like a waste of time to me. *If I were going to port to any
>> >> other crypto library, I'd port to gcrypto, not NSS.
>>
>> > See also that suse consider to port to nss
>> > http://old-en.opensuse.org/SharedCertStore
>>
>> That's fine. They can send me patches too if they want. I'm still
>> not interested; I'd rather put whatever time I had into making gnutls and
>> gcrypto better, particularly since I think FIPS certification is just a
>> money-making racket.
>
> 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.

/Simon


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87vcxy34kj.fsf@latte.josefsson.org">http://lists.debian.org/87vcxy34kj.fsf@latte.josefsson.org
 
Old 04-28-2011, 01:31 PM
Roger Leigh
 
Default 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
broken.

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
effect.

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.


Regards,
Roger

--
.'`. 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.
 
Old 04-28-2011, 01:31 PM
Roger Leigh
 
Default 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
broken.

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
effect.

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.


Regards,
Roger

--
.'`. 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.
 
Old 04-28-2011, 03:49 PM
Clint Adams
 
Default Crypto consolidation in debian ?

On Thu, Apr 28, 2011 at 10:37:37AM +0200, Bastien ROUCARIES wrote:
> So, could we document we different pitfall of crypto library on the
> debian wiki ?

You could use http://curl.haxx.se/docs/ssl-compared.html
and http://en.wikipedia.org/wiki/Comparison_of_TLS_Implementations
as starting points.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110428154931.GA32454@scru.org">http://lists.debian.org/20110428154931.GA32454@scru.org
 
Old 05-01-2011, 01:23 AM
Steve Langasek
 
Default 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.

As a comaintainer of openldap, which links to gnutls in Debian for license
reasons, I need to vehemently echo Roger here. sudo most certainly isn't
broken for being setuid, and libgcrypt should definitely not be ripping its
suid privs out from under it, yet this is what happens if using nss_ldap
with an SSL-using LDAP server.

http://bugs.debian.org/566351
https://bugs.launchpad.net/bugs/423252

Changing the uid of the calling application is *not* an acceptable side
effect for a library and I can't imagine how anyone could believe that it
is. Unfortunately that seems to leave nss_ldap caught between an SSL
implementation with a perverse license, and an SSL implementation whose
upstream has perverse ideas about library handling of process state.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110501012328.GB22825@virgil.dodds.net">http://lists.debian.org/20110501012328.GB22825@virgil.dodds.net
 
Old 05-01-2011, 10:55 AM
Bastien ROUCARIES
 
Default Crypto consolidation in debian ?

On Sun, May 1, 2011 at 3:23 AM, Steve Langasek <vorlon@debian.org> wrote:
> 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.
>
> As a comaintainer of openldap, which links to gnutls in Debian for license
> reasons, I need to vehemently echo Roger here. *sudo most certainly isn't
> broken for being setuid, and libgcrypt should definitely not be ripping its
> suid privs out from under it, yet this is what happens if using nss_ldap
> with an SSL-using LDAP server.
>
> *http://bugs.debian.org/566351
> *https://bugs.launchpad.net/bugs/423252
>
> Changing the uid of the calling application is *not* an acceptable side
> effect for a library and I can't imagine how anyone could believe that it
> is. *Unfortunately that seems to leave nss_ldap caught between an SSL
> implementation with a perverse license, and an SSL implementation whose
> upstream has perverse ideas about library handling of process state.

It seems fedora is moving to nss for openldap

https://fedoraproject.org/wiki/Test_Day:2010-10-14_OpenLDAP/NSS

Have you tested ?

Bastien


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: BANLkTind2XtFLBr5y8_4v=+UMfNbzB+fbw@mail.gmail.com ">http://lists.debian.org/BANLkTind2XtFLBr5y8_4v=+UMfNbzB+fbw@mail.gmail.com
 
Old 05-01-2011, 12:29 PM
Andreas Metzler
 
Default Crypto consolidation in debian ?

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().

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.

cu andreas

--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: ja0098-mlf.ln1@argenau.downhill.at.eu.org">http://lists.debian.org/ja0098-mlf.ln1@argenau.downhill.at.eu.org
 
Old 05-01-2011, 01:08 PM
Andreas Metzler
 
Default Crypto consolidation in debian ?

Andreas Metzler <ametzler@downhill.at.eu.org> wrote:

> Also libgcrypt does seem to be designed to be used indirectly
^
|
not


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: vi2098-aul.ln1@argenau.downhill.at.eu.org">http://lists.debian.org/vi2098-aul.ln1@argenau.downhill.at.eu.org
 
Old 05-01-2011, 01:08 PM
Roger Leigh
 
Default 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.


Regards,
Roger

--
.'`. 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.
 
Old 05-01-2011, 01:17 PM
Andreas Barth
 
Default Crypto consolidation in debian ?

* Roger Leigh (rleigh@codelibre.net) [110501 15:08]:
> 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.

I miss (not only here) the principle:
First, do no harm.

Which are totally failed by a library changing uids on it's own.



Andi


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110501131714.GE15003@mails.so.argh.org">http://lists.debian.org/20110501131714.GE15003@mails.so.argh.org
 

Thread Tools




All times are GMT. The time now is 10:16 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org