<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Nov 23, 2022 at 2:06 PM Michael Kjörling <<a href="mailto:9bf3a7ef93bb@ewoof.net">9bf3a7ef93bb@ewoof.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 22 Nov 2022 14:56 +0000, from <a href="mailto:hbaker1@pipeline.com" target="_blank">hbaker1@pipeline.com</a> (Henry Baker):<br>
> Consider Unix/Linux read/write/execute/owner/group protections.<br>
> <br>
> Wouldn't 'execute' be analogous to today's 'trusted boot' chains ?<br>
> <br>
> Presumably 'owner' would be connected to a public key for the owner.<br>
> <br>
> Are there crypto versions of 'group' ?<br>
<br>
A group is just a named set consisting of some (non-negative but<br>
possibly zero) number of specified users. So if the concept of owner<br>
(a user) maps to a single public key, then the concept of group would<br>
likewise map to a set of public keys any one of which is sufficient to<br>
authorize the action in question.<br>
<br>
As long as we ignore performance, that makes it easy: if you already<br>
have some function authorized_for(action, identity) where action<br>
represents some action to be taken, identity is a user's public key or<br>
other identity-bearing token, and the return value somehow indicates<br>
whether the action is allowed or not; then all you need is a way to<br>
iterate over a set of values of identity until that function either<br>
returns "allowed" or you run out of identities to try (the latter<br>
resulting in an ultimate result of disallowed).<br>
<br>
For proper protection you would of course want that to be an atomic<br>
part of, for example, the I/O code path, not a separate test, but I'm<br>
simplifying here to illustrate the possible solution given the set of<br>
building blocks.<br></blockquote><div><br></div><div class="gmail_default" style="font-size:small">I have spent quite a bit of time thinking about how to do this in the cloud. Inside the CPU... well that is another question and the answer is likely to be 'yes you can meet the technical requirement but not in a fashion that is actually useful'.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">First off, file system protections today are based on 1970s technology and limited to static access control. If you want good security, you want dynamic access control and accountability (which is what the Mesh provides). So no, Chealsea Manning cannot download 90,000 diplomatic cables because the management system cuts her off at 2,000 (or so) and she is deterred from attempting to exceed her authority by the knowledge that every access is logged.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So as far as confidentiality is concerned, I can't see the value. Anyone who is so deeply into security to care is going to want dynamic access control.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">But let's get back to the attack model, what are we really talking about here? Prevent SPECTRE or ROWHAMMER type attacks? How about code injection?</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I think we can probably do much better with narrower controls. We can separate ECDH operations onto a separate CPU just for that, poof! SPECTRE type attacks are gone. And many chips already have that (latent) capability because they have integrated TPMs.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">For ROWHAMMER, some sort of integrity control is more likely to be effective, no?</div><div class="gmail_default" style="font-size:small"><br></div></div></div>