<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Den fre 9 apr. 2021 22:43Ray Dillinger <<a href="mailto:bear@sonic.net">bear@sonic.net</a>> skrev:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">[...]<br>
<br>
Disk encryption that actually provides the protections people think disk<br>
encryption provides would require a whole new filesystem type, a whole<br>
new OS mostly organized around key management, and APIs that<br>
applications have to *use* (or else the application DOESN'T WORK) to<br>
specifically encrypt writes and decrypt reads.  'Reading' keys (half a<br>
symmetric pair) would be available in accounts having read permission to<br>
some file, and 'Writing' keys (both sides of a symmetric pair) would be<br>
available in accounts having write permissions to the file.  If it's an<br>
executable or a script, then it requires a different pair of keys;<br>
'execute' permission would have half a symmetric pair and 'write<br>
executable' would have both halves. <br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">This is how Tahoe-LAFS works, although it's not intended for use as a local file system but rather as network based multi-server file storage. Nothing stops you from hosting it all locally, though. </div><div dir="auto"><br></div><div dir="auto">As a user who is accessing files hosted by this system you have read keys and/or read+write keys, and the server (and hopefully also any adversaries) has neither. Read keys are normal symmetric keys, while write keys is both this symmetric key plus a private key for a signing keypair. When reading files you also verify the signature. </div><div dir="auto"><br></div><div dir="auto">You can use such a system to build more granular permissions, such as using different write keys and different read keys for various files and then controlling who has access to each key and setting metadata flags. </div><div dir="auto"><br></div><div dir="auto">This may of course include using separate keys for executables, and potentially metadata tags to tell the OS that only certain error write keys are associated with executable permissions, controlled by a system administrator (mimicking a capabilities model). In this case a user which lacks write keys with executable permissions would only be able to run an executable file which was created by some user who does have a write key with executable permissions (such as the admin themselves). </div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>