Bug#368297: About the libgcrypt and OpenLDAP issue

[Werner Koch]

On Fri, 19 Apr 2013 02:52, mgilbert at debian.org said:
>>> 1.a) Patch libgcrypt to revert commit
>>>      d769529a71ccda4e833f919f3c5693d25b005ff0
>>
>> Urgs.  That is a short sighted fix.
>
> That seems to be the solution the rest of the open source community is
> converging toward.  Short sighted is an odd categorization since it
> seems to have taken 8 years to come to this conclusion.

Misunderstanding?  With "a short sighted fix" I mean 1.a; that is the
proposal to _revert_ commit d769529.

Anyway, this commit is there for a good reason; I can't remember any
details but for sure Moritz had a valid reason to do this.  Those who
are interested may want to do dig the gnupg/gcrypt/poldi archives.

The whole mess comes from the idea that a library is able to deduce what
the application wants to do without the application telling it.  Now if
a library is used indirectly by the application and often also from
several libraries and even from the application itself, conflicts will
arise.  Thus we have always told that an application must be aware of
_all_ code it is using in its process.  Thus libraries may need to
expose an interface to the application even if they are used indirectly.
Using shared libraries is not easy and sometimes it is impossible to get
things right (in OSes where shared libraries have been added as an
afterthought).  And yes, Libgcrypt is not an exception: It also does
guess working and assumes that complex application won't run suid.  And
it tries to be as failsafe as possible by trying hard to initialize
itself if the application forgot to do that.

It seems the main reason for all that hassle is the ad-hoc architecture
of PAM being a set of libraries instead of a daemon and a library to
access that daemon (like userv(1)).  PAM's track record of security
problems might be an indication of that architectural problem.

> Maybe some of the blogs on the issue and other comments in this bug
> log would be of useful to understand why.  For example:
> http://jdbates.blogspot.ca/2013/04/its-crazy-how-much-time-and-effort-one.html

While we are in the business of refreshing our URL memories, let me
follow up with:

 http://thread.gmane.org/gmane.comp.encryption.gpg.libgcrypt.devel/2198

Florian Weimer comes to the same conclusion regarding the PAM
architecture but also asked why we still need a suid for mlock.  The
simple reason is that some installations still use suid(e.g. gpg) and
rely on Libgcrypt dropping the privileges.  Thus we can't change that.

A solution would be that the application explicitly tells us not to drop
the privileges.  libpam can't do that because it does not know anything
about the application.  But wait, the bug at hand is about a specific
application and thus sudo would be able to tell libgcrypt what to do.
Adding a global flag to Libgcrypt to skip privilege dropping will not be
hard; let me know if this could be a way forward.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.