Alice wants to be able to share read and write access to some of her files (on a unix system) with dynamically changing sets of users. Since she is not root, she can't just construct new groups for each file, nor can she turn on the optional ACL feature available on some Linux systems. So she decides to write setuid programs that will implement ACLs for her friends. Alice designs two setuid, world- executable programs, alice-write and alice-read (e.g., programs that anyone can run as alice ) that work as follows: . /alice-write IN OUT: first checks a permission file written by Alice to make sure that the ruid of the process (the calling user) is allowed to write to the file out. If so, then the program reads the file in and writes it over out. ./alice-read IN OUT: first checks a permission file written by Alice to make sure that the calling user is allowed to read the file in. If so, the the program reads in and writes it to the file out. Assume Alice has been careful in her implementation, i.e., there are no buffer overflows in alice-read and alice-write, the permission file is properly protected (uniquely named in the program and set to permission 0400), the programs accept only file paths listed in the permissions file, and permissions on Alice's files are preserved. 1. Can you find any (21) potential security problems with this approach? Describe them, no code/visuals required. (e.g., suppose Bob can read and write some of Alice's files but not others; can he use alice-write and alice-read to gain access to files he shouldn't? Are there potential attacks that could allow third parties to read/write Alice's files?) (10 points) 2. How could you change interface (e.g., what is passed to the programs) and/or implementation (e.g., the description of the programs) of alice-write and alice-read to avoid your attacks? Describe only, no code necessary. [10 points] Alice wants to be able to share read and write access to some of her files (on a unix system) with dynamically changing sets of users. Since she is not root, she can't just construct new groups for each file, nor can she turn on the optional ACL feature available on some Linux systems. So she decides to write setuid programs that will implement ACLs for her friends. Alice designs two setuid, world- executable programs, alice-write and alice-read (e.g., programs that anyone can run as alice ) that work as follows: . /alice-write IN OUT: first checks a permission file written by Alice to make sure that the ruid of the process (the calling user) is allowed to write to the file out. If so, then the program reads the file in and writes it over out. ./alice-read IN OUT: first checks a permission file written by Alice to make sure that the calling user is allowed to read the file in. If so, the the program reads in and writes it to the file out. Assume Alice has been careful in her implementation, i.e., there are no buffer overflows in alice-read and alice-write, the permission file is properly protected (uniquely named in the program and set to permission 0400), the programs accept only file paths listed in the permissions file, and permissions on Alice's files are preserved. 1. Can you find any (21) potential security problems with this approach? Describe them, no code/visuals required. (e.g., suppose Bob can read and write some of Alice's files but not others; can he use alice-write and alice-read to gain access to files he shouldn't? Are there potential attacks that could allow third parties to read/write Alice's files?) (10 points) 2. How could you change interface (e.g., what is passed to the programs) and/or implementation (e.g., the description of the programs) of alice-write and alice-read to avoid your attacks? Describe only, no code necessary. [10 points]
