[Cryptography] Use Linux for its security

Ray Dillinger bear at sonic.net
Fri Sep 30 01:07:07 EDT 2016



On 09/29/2016 05:45 AM, J.M. Porup wrote:
> On Wed, Sep 28, 2016 at 12:39:15PM -0400, Jerry Leichter wrote:

>> The fundamental criticism is that Linux is way behind the times: 
>> It's still trying to squish one security bug at a time, rather than
>> using more modern techniques that close off entire classes of
>> attacks, even if no specific ones have been identified...

> As the author of the Ars Technica article mentioned, I concur. If
> this subject interests you, please go to the primary sources and
> watch the videos--you can read me quoting Kees Cook, or you can watch
> his talk yourself.

Given the writ to do a clean slate design, the mandate to design for
security, and a tolerance for performance costs implicit in secure
design, I think we really could fix most of the problem.

Here is how to build a drastically more secure operating system. Isolate
every process in its own address space sharing memory with zero other
processes, handle privileges with a capability system, and use a
microkernel to get as much stuff as possible to NOT run with default or
root privileges.

 There would be no ABI as we understand it.  All interprocess
communication, including what we now think of as calls into runtime
libraries, calls to DLLs or shared objects, and calls into the OS, would
be handled by daemons communicating with other processes via named
pipes.  Most of them (possibly every one that provides an accessible
service) would share zero address space with the kernel itself, or with
the processes requesting their services, or even with each other.

We could use a REAL encrypted filesystem; rather than just emulating an
unencrypted filesystem with the bulk storage  transparently 'mounted'
whenever the machine is running, we could enforce file level access
privileges using crypto.  IE, the filesystem daemon accepts and returns
only ciphertext, you don't have the key to decrypt anything you don't
have the capability to read, and you don't have the key to encrypt
anything you don't have the capability to write.

A real encrypted filesystem could do other things as well; for example
you could have ciphertext-only read capabilities to enable people to do
routine backups etc without ever gaining the ability to read the bits
they're making backups of.

Even without support from an encrypted filesystem, logfiles could
contain blockchain-type sequential hashes to make modification of
logfiles after the fact extraordinarily easy to detect or else damned
hard to do.

It would have very poor performance relative to other OS, in terms of
responsiveness.  Sequential communications rather than ABI calls means
lag.  It would use a lot more memory and CPU to get its work done.  But
it would absolutely shut down most existing types of privilege
escalation and access insecurities, and shut them down HARD.

Bear

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20160929/cbfa22bf/attachment.sig>


More information about the cryptography mailing list