[Cryptography] Transactional software updates

[Tom Mitchell]

On Thu, Oct 26, 2017 at 10:01 PM Phillip Hallam-Baker <phill at hallambaker.com>
wrote:

> I think the talk of file systems is missing the point here.
>
> Yes, you can do stuff that requires kernel mode features and a fancy
> file system.

......

> If the necessary indexes are provided, there is no reason that most
> software distributions couldn't simply execute straight out of the
> distribution zip file.
>
> I really, really dislike the idea that any code that is not shipped by
> the platform vendor should ever modify any part of the platform. I
> detest shared libraries, I see absolutely no reason for them on modern
> machines when a 0.25 TB SD card can be had for a few bucks.
>
......

>
> The only time a shared library is ever justified

....

Rather than using shared libraries, I would like to see the use of
> approaches that strip down linked libraries to exactly the methods
> that are actually


Shared libraries in addition to saving RAM and disk space also
distribute maintenance.  A consumer of a library “should” need to
know no more than the API of the function and methods being used.

Once things get stripped down and only contain the exact set of functions
used the author quickly is responsible for evaluating all changes and
rebuilding
the application.  That is difficult enough that many will rebuild if the
library
gets touched.

In *nix  there is a key set of programs that are fully linked to .a files
and are fully self contained but the full library is linked not the subset
of the library.

The go language and compiler offer some help.  The incremental compile and
linking
builds on previous compiled bits and builds fresh the necessary when
foundation code changes.
It still uses system shared libraries but those could be rewritten in go so
the environment
extends to the systemcall API&ABI.

This does not solve interpreted language issues like shell, awk, bash,
Perl, python, php, ruby...
Also prelink tools and steps need to be addressed.  The runtime linking
needs help to sort
the  address space link hints. A defensive trick to randomize link
addresses also needs review.

Encryption tricks might help to validate each object before loading.
Dwarf/elf/coff execution format files rich in link and debug info could
also contain signatures and check sums.   Debugging and debuggers mess
with security.

With a 64  bit address space a single library file (memory mapped) could be
built that  has
a single address lookup table.   i.e.  A grandlib.so file could be
assembled and
updated with a single inode pair (old, new) and simplify the atomic file
action.

Such a grandlib resource does need assurance.  It might need to be
encrypted
not unlike an encrypted file system and mounted only for a validated binary.

Backing off from the full Win/Linux system problem the tiny (giggle) IOT
devices do present
a more limited universe for these problems.  As small as they appear the
Security
issues are large.
What assurance foundations including crypto are necessary for IOT resources.
N.B. A Raspberry Pi is computationaly on a par with a Cray 1.








-- 
Tinny keyboard.. Mobile ... I am
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20171030/b86f4363/attachment.html>