8. The Means of Cybersecurity: Access Control 205 permissions in OSs. An OS’s documentation would explain how conflicting permissions are resolved, and users can perform experiments to see for themselves how different situations are handled. In this case, on a Windows and Linux OS, bob’s permissions are the union of his individual permissions and the permissions for all the groups he is in. Therefore, he would have permission to run gedit. One exception would be on a Windows system if bob had or was in a group with a negative permission that denied him access. Negative permissions take precedence over positive permissions when they are in conflict. Figure 8.6 Linux OS file tree starting from bob’s home directory. Another complexity that arises with permissions in OSs are inheritance rules. For example, if a user is given permission to read a directory, then by inheritance, he can view all the files and directories under that directory. Similarly, if he is given permission to write a directory, then he can create subdirectories underneath that directory. OSs do not implement a data structure like the full permission matrix illustrated in Table 8.2. Instead, they track and enforce authorization by associating lists of user permissions with files. In other words, files “carry around” their sets of permissions. This method of managing permissions is called access control lists (ACLs). Figure 8.7 shows the ACL for a Python script in a Linux OS called stegdecode.py. It details that the user bob has RWX permissions on the file. This means that bob (user in Figure 8.7) can read the script, edit the script, and run the script. Meanwhile, all users in the student group can read and run the script, but they cannot edit it. All other users (other) have no permissions on the script, so they cannot view it, modify it, or run it. Windows also uses ACLs. Figure 8.5 above shows an ACL for the blog-home.bmp file. It shows that the SYSTEM user has full
RkJQdWJsaXNoZXIy MTM4ODY=