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

[Tom Mitchell]

On Sat, Apr 19, 2014 at 4:50 PM, Bear <bear at sonic.net> wrote:
>
>
> I have to say the OpenSSL guys really and truly had a point when they
> pointed out that dynamic linking is not fully or easily compatible
> with the goal of security libraries.
>
> Inconvenient as it was for Apple (and inconvenient as it is for others)
> we really shouldn't be relying on dynamic linking to load security
> modules.  Remember, in security we're in the business of guaranteeing

Yes, The loading of libraries makes screen doors out of many
cases that should be solid oak.   But they do have advantages...

The value is when a library is updated by someone with
domain specific knowledge regarding that library you
can profit from their homework the next time your application
is updated.

One working model built on fully linked objects can be seen in Trusted Irix.
Trix contained  a modest list of objects shell, ld ... that
were fully linked (to .a)  and did not need to import a shared object.
 http://oss.sgi.com/projects/ob1.nuked/doc/html/

The alternative is worse than Gentoo is today.  Gentoo does have
shared objects so emerging the world is not 100%.

Gentoo is bad just not as bad as a system built with Google go where
you might not know that something in a big cloud of shared code
changes.  You only
know when you recompile and watch to see if the system pulls
the new stuff up and into your package and if your cloud view
is current.

Yes it is possible to have a deep revision control repository
and constantly check, review and decide.  How big look
at the likes of "lsof" and pick one or more processes you
might care about and explore how difficult it would be to
keep the list current and rebuild them and your app:
$ lsof -p 1592| grep lib
systemd 1592 mitch  txt       REG                8,2  1210216
155403 /usr/lib/systemd/systemd (deleted)
systemd 1592 mitch  mem       REG                8,2    92560
181036 /usr/lib64/libz.so.1.2.8
systemd 1592 mitch  mem       REG                8,2    22160
188278 /usr/lib64/libattr.so.1.1.0
systemd 1592 mitch  mem       REG                8,2   116248
188271 /usr/lib64/libnsl-2.18.so
systemd 1592 mitch  mem       REG                8,2   155400
185822 /usr/lib64/liblzma.so.5.0.99
systemd 1592 mitch  mem       REG                8,2   421144
187973 /usr/lib64/libpcre.so.1.2.1
systemd 1592 mitch  mem       REG                8,2    22440
176704 /usr/lib64/libdl-2.18.so
systemd 1592 mitch  mem       REG                8,2  2100672
176700 /usr/lib64/libc-2.18.so
systemd 1592 mitch  mem       REG                8,2   150800
176702 /usr/lib64/libpthread-2.18.so
systemd 1592 mitch  mem       REG                8,2    91352
187983 /usr/lib64/libgcc_s-4.8.2-20131212.so.1
systemd 1592 mitch  mem       REG                8,2   306760
168996 /usr/lib64/libdbus-1.so.3.7.4
systemd 1592 mitch  mem       REG                8,2    47400
187981 /usr/lib64/librt-2.18.so
systemd 1592 mitch  mem       REG                8,2    91408
178024 /usr/lib64/libkmod.so.2.2.5
systemd 1592 mitch  mem       REG                8,2    21424
188279 /usr/lib64/libcap.so.2.22
systemd 1592 mitch  mem       REG                8,2   116872
173188 /usr/lib64/libaudit.so.1.0.0
systemd 1592 mitch  mem       REG                8,2    64048
188782 /usr/lib64/libpam.so.0.83.1
systemd 1592 mitch  mem       REG                8,2    44696
188272 /usr/lib64/libwrap.so.0.7.6
systemd 1592 mitch  mem       REG                8,2   144952
189074 /usr/lib64/libselinux.so.1
systemd 1592 mitch  DEL       REG                8,2
189198 /usr/lib64/libudev.so.1.4.0
systemd 1592 mitch  DEL       REG                8,2
153310 /usr/lib64/libsystemd-daemon.so.0.0.10;5352ecff
systemd 1592 mitch  mem       REG                8,2   157200
176698 /usr/lib64/ld-2.18.so

SUMMARY:
Shared libraries are OK with me.
Your opinion or management may have other opinions.


-- 
  T o m    M i t c h e l l