[Cryptography] Are dynamic libs compatible with security? was: Apple and OpenSSL

[Bill Cox]

On Sat, Apr 19, 2014 at 11:36 PM, Jerry Leichter <leichter at lrw.com> wrote:

> So for MacOS-style applications, the static vs. dynamic issue is as much
> or as little of an issue as you choose to make it.  Any libraries placed in
> the appropriate directories under the Foo.app directory are "morally
> statically linked":  The program will always choose them first, ahead of
> anything else on the system.  System libraries aren't normally carried
> along with applications, but nothing (as far as I know) says they can't be.
>
> So all this concern is related to programs built and run the old-fashioned
> way, as simple executable files that dynamically load from the system
> library path.  Applications built as .app files can easily carry along as
> little or as much of their environment as appropriate.  For code that
> relies on OpenSSL, carrying along a private copy that you code was built
> against seems like a fine idea.  But you do have to package it all up in
> MacOS style - something your typical OSS projects, supporting multiple
> platforms, are unlikely to want to bother with.
>
>                                                         -- Jerry
>
>
> _______________________________________________
> The cryptography mailing list
> cryptography at metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography
>

This is almost the right way to ship and update applications.  Every
application is tested with a fixed set of shared libraries, and that is the
set that likely will be most stable over time.  Updating shared-libraries
underneath an application is not just insecure, it's a great way to
introduce bugs.

The right way to do applications is much like this, where we also run each
application in it's own security jail (as Android does - I don't personally
bother reading anything from an organization as evil as Apple, so I don't
know what they do).

In addition, to save on space, identical binaries should only exist on disk
once.  This can be done trivially with hard links.  Finally, there should
be a way to do "critical" updates of libraries.  For example, all the apps
linking to OpenSSL, should be updated after the Heartbleed discovery.  The
application authors should mostly lock down the libraries they link to, but
the distro maintainer should be able to override those choices in critical
situations.

I can't even begin to explain here how many benefits such a system would
have for GNU/Linux.  GNU/Linux is losing the OS war for the desktop.  The
way GNU/Linux is built and distributed requires insane testing and
maintenance, which is why you can't just publish an app today, and access
it in Debian Stable tomorrow.  GNU/Linux is basically designed to break,
and the way we work around that stifles innovation.  GNU/Linux needs an
Android-inspired App delivery system.

Bill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20140420/029e1369/attachment.html>