In standard systems, there is a [[TCB - Trusted Computing Base]] that runs on a single node. User has a trusted path to the TCB. In comparison, in [[Distributed systems|distributed systems]], user is on a client machine which is different from the server that provides access to the protected resource. Client and server may be separated by an open network. ![[attachments/Screenshot 2023-07-13 at 4.50.29 PM.png]] The user/principal is on the client host and is communicating on an open network with the service host. The service host has protected resources that are protected by the TCB. > Here, the attacker will be able to see the open network. Principals make requests to perform operations on objects that reside on remote hosts. The reference monitor on the remote host makes deny/grant decisions. The reference monitor needs to know who is making the request and authorize this request with an access control policy. ### Challenges - [[Authentication|Authentication]] when a direct trusted path does not exist between user and TCB. - [[Authorization]] when requests come over the network and someone else (like a network channel) has to make the request on behalf of the user. - Access control policy enforcement might be defined across different entities. ### Handling requests in distributed systems A user does not directly request a resource R from the TCB on the server machine. Instead of directly making the request, the request comes through a communication channel. The access control policy defines who has access to a given resource. >[!info] As long as the principal making the request can be trusted at least as much as some principal having access to R, they will get access granted. #### Communication channels Communication channels are the principals that directly deliver requests to the server. These channels are things like network connections, system calls, and decryption of encrypted messages. With encrypted communications, keys can be principals. #### Theory and practice of securing distributed systems - Theory allows us to make precise statements that pertain to security relevant actions. - Practice addresses actual protocols and their implementation. - Security analysis helps us convince why the system is secure against certain threats. --- ### Example scenario A user might be using an accounting app that wants to read a file from a server. ![[attachments/Screenshot 2023-07-13 at 5.10.56 PM.png]] Here are some relevant questions from the server's perspective: - Who is the requesting user? - [[Authentication]] problem - Is the application legitimate or is it compromised? Is it a trojan? - How do we know for sure if it is an accounting application that is asking to read the file? Maybe the OS can tell us. - Can we trust the OS? - How do we know if we can trust the OS to tell us which applications are running? We need the hardware’s help. - Is the hardware who it claims to be? - Is the communication channel secure? - Could an attacker have affected the request’s integrity in-transit? from the client's perspective: - Is the server who it claims to be? - Can the server OS be trusted? - Can the server's file system be trusted? #### Assumptions We need to make some assumptions to answer the above set of questions. Assumptions about trust and authority: - Hardware and local OS, when booted securely, are trusted - There are hardware security vulnerabilities, but it is the responsibility of the hardware security team. - Encrypted channels are secure and trusted - Cryptographic schemes are not fully secure, but out of our scope here. We need to state our assumptions precisely when discussing theory. > Goal: Other than the assumptions, everything else needs to be built in a demonstrably trusted manner.