[Cryptography] General security infrastructure suggestion: where to take it?

[Natanael]

Den 28 dec 2014 04:59 skrev "Ray Dillinger" <bear at sonic.net>:
>
> This is not specifically cryptographic, although an implementation
> of it in a secure file system might be.  Any suggestions about
> what would be a better venue for bringing this up would be
> appreciated.
>
> The Unix permissions convention of root:group:user is IMO no
> longer really adequate for the security issues we're facing at
> this point, and should probably be replaced with a convention
> of root:usergroup:user:exegroup:executable.
>
> The evolution I propose changes the structure of file permissions
> to keep track of a program/program group having privileges over
> that file, and gives the users access to tools for administering
> the privileges of programs/program groups running under their
> own login.

Capabilities based OS design.

You can find helpful pointers in https://reddit.com/r/netsec and
https://reddit.com/r/capabilities (IIRC). Many capabilities based systems
use cryptographic tokens to control access and layers of encryption, such
that even an exploit to gain access to memory it shouldn't have won't give
it access to either reading privileged plaintext or modifying it.

Android does this to some degree, but not fully. It just isolates apps in
sandboxes and then offers a number of standardized channels for
communicating with each other, and there's no granular access controls so
far for your personal data regarding reading (kitkat introduced restricted
write access to the SD card, but not for the internally stored files).

IMHO what should be done is that everything run under a user account should
be run in isolated sandboxes, only giving access for communication between
sandboxes when both programs agree or the user says so. One of the greater
benefits for this is that user level malware can't then tamper with your
terminal when you run a command with sudo, so it can't perform privilege
escalation by piggybacking legitimate software silently (today the terminal
is often unprotected software, there's no way to launch it such that you
can protect it from malicious code).

And all software should eventually be redesigned to support running
sandboxed, to support communicating mainly via limited channels, and so on.
And file access and system privileges and user privileges would have to be
requested and assigned individually to the sandboxed software. Inside user
accounts, it really should be "sandboxes all the way down", as a
configuration screw-up putting malware in control should allow you to
access the account in a "safe mode" to reset permissions and clear it
malware. There shouldn't simply be "inside app sandboxes" and "outside app
sandboxes" within accounts.

A sandboxed version of KDE's workspaces would be even better, this would go
much further than Qubes OS. You'd have multiple completely isolated
desktops with different configurations, one for work, one for browsing,
etc, and software within one wouldn't even know of the other workspaces.
Different folders in your account would only be accessible from certain
workspaces to even further limit the what malware can do.

Also note that Android's runtime ties apps to their sandboxes sandboxes in
a way which allows other apps to verify them by their signature and package
name. This means that apps from developers which trust each other can give
automatic access to certain functionality in between the apps. An office
suite wouldn't need to distribute all apps together, yet they could be
allowed access to each other's private data as you can be sure they aren't
malicious. Just check that the sandbox you get a request from belongs to
program X with the correct signature, and no malicious software can tamper
with it (unless program X has an exploit in how it handles inputs, though).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20141228/030bc5dd/attachment.html>