<br><div class="gmail_quote" dir="auto"><div dir="auto">On Thu, Oct 26, 2017 at 10:01 PM Phillip Hallam-Baker <<a href="mailto:phill@hallambaker.com">phill@hallambaker.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think the talk of file systems is missing the point here.<br>
<br>
Yes, you can do stuff that requires kernel mode features and a fancy<br>
file system.</blockquote><div dir="auto">......</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If the necessary indexes are provided, there is no reason that most<br>
software distributions couldn't simply execute straight out of the<br>
distribution zip file.<br>
<br>
I really, really dislike the idea that any code that is not shipped by<br>
the platform vendor should ever modify any part of the platform. I<br>
detest shared libraries, I see absolutely no reason for them on modern<br>
machines when a 0.25 TB SD card can be had for a few bucks.<br>
</blockquote><div dir="auto">......</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
The only time a shared library is ever justified </blockquote><div dir="auto">....</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Rather than using shared libraries, I would like to see the use of<br>
approaches that strip down linked libraries to exactly the methods<br>
that are actually </blockquote><div dir="auto"><br></div><div dir="auto">Shared libraries in addition to saving RAM and disk space also </div><div dir="auto">distribute maintenance. A consumer of a library “should” need to </div><div dir="auto">know no more than the API of the function and methods being used.</div><div dir="auto"><br></div><div dir="auto">Once things get stripped down and only contain the exact set of functions </div><div dir="auto">used the author quickly is responsible for evaluating all changes and rebuilding </div><div dir="auto">the application. That is difficult enough that many will rebuild if the library</div><div dir="auto">gets touched. </div><div dir="auto"><br></div><div dir="auto">In *nix there is a key set of programs that are fully linked to .a files</div><div dir="auto">and are fully self contained but the full library is linked not the subset </div><div dir="auto">of the library. </div><div dir="auto"><br></div><div dir="auto">The go language and compiler offer some help. The incremental compile and linking</div><div dir="auto">builds on previous compiled bits and builds fresh the necessary when foundation code changes. </div><div dir="auto">It still uses system shared libraries but those could be rewritten in go so the environment </div><div dir="auto">extends to the systemcall API&ABI. </div><div dir="auto"><br></div><div dir="auto">This does not solve interpreted language issues like shell, awk, bash, Perl, python, php, ruby...</div><div dir="auto">Also prelink tools and steps need to be addressed. The runtime linking needs help to sort </div><div dir="auto">the address space link hints. A defensive trick to randomize link addresses also needs review.</div><div dir="auto"><br></div><div dir="auto">Encryption tricks might help to validate each object before loading.</div><div dir="auto">Dwarf/elf/coff execution format files rich in link and debug info could</div><div dir="auto">also contain signatures and check sums. Debugging and debuggers mess</div><div dir="auto">with security. </div><div dir="auto"><br></div><div dir="auto">With a 64 bit address space a single library file (memory mapped) could be built that has </div><div dir="auto">a single address lookup table. i.e. A grandlib.so file could be assembled and </div><div dir="auto">updated with a single inode pair (old, new) and simplify the atomic file action.</div><div dir="auto"><br></div><div dir="auto">Such a grandlib resource does need assurance. It might need to be encrypted </div><div dir="auto">not unlike an encrypted file system and mounted only for a validated binary.</div><div dir="auto"><br></div><div dir="auto">Backing off from the full Win/Linux system problem the tiny (giggle) IOT devices do present</div><div dir="auto">a more limited universe for these problems. As small as they appear the Security </div><div dir="auto">issues are large. </div><div dir="auto">What assurance foundations including crypto are necessary for IOT resources.</div><div dir="auto">N.B. A Raspberry Pi is computationaly on a par with a Cray 1. </div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div></div><div dir="ltr">-- <br></div><div class="gmail_signature" data-smartmail="gmail_signature">Tinny keyboard.. Mobile ... I am</div>