Computer Systems Security: Winter 2018 Assignment 1: Difference between revisions
(9 intermediate revisions by the same user not shown) | |||
Line 26: | Line 26: | ||
# Yes, it is possible. For example, if we set the permissions of foo.txt to 066, then everyone except for the file owner will be able to read and write the file. (Of course, the owner can change these permissions at any time.) | # Yes, it is possible. For example, if we set the permissions of foo.txt to 066, then everyone except for the file owner will be able to read and write the file. (Of course, the owner can change these permissions at any time.) | ||
# Read permission lets you list the files in a directory. Execute permission lets you open or execute a file named in the directory. You can verify this by setting only read or execute permissions with the chmod command (e.g., chmod a-r to remove read permissions, chmod a-x to remove execute permissions) and then seeing what access you have. | # Read permission lets you list the files in a directory. Execute permission lets you open or execute a file named in the directory. You can verify this by setting only read or execute permissions with the chmod command (e.g., chmod a-r to remove read permissions, chmod a-x to remove execute permissions) and then seeing what access you have. | ||
# | # Normally anyone who can write to a directory can also remove any file in the directory (as write privileges implies unlink privileges). If the sticky bit is set on such a directory with the command "chmod +t", however, users can only unlink their own files. Thus the sticky bit is normally set on system temporary file directories (e.g., /tmp, /var/tmp) and other world-writable directories. | ||
# | # Setuid binaries have the setuid bit set (chmod u+s). This bit instructs the kernel to change the effective uid of the process after an execve to the owner of the exec'd binary. Setuid root binaries are binaries that are owned by root with the setuid bit set; thus, when they are run, they run with full root privileges. | ||
# | # Setuid root binaries are important because they allow unprivileged users to perform privileged operations under controlled circumstances, such as changing their password or mounting a filesystem. Without setuid root binaries, the only way for a unprivileged user to perform a privileged operation on UNIX would be to communicate with a process that already had privileges (e.g., a privileged process listening on a socket). | ||
# | # The risk of setuid root binaries is that 1) they can be run by unprivileged users and 2) they can perform privileged operations. If there is a flaw in such a binary, then unprivileged users can perform privileged tasks or even obtain full privileges when they shouldn't be able to. Thus, every setuid root binary represents an opportunity for an attacker to subvert the entire UNIX security model. | ||
# | # There are many possible examples. A simple one is a passwd binary that doesn't properly restrict arbitrary password changes to the root user (e.g., there is a logic error in the code restricts arbitrary password changes to root). If this is the case, then any user can change anyone else's password. | ||
# | # TCP wrappers and host-based firewalls prevent services from being accessed from arbitrary hosts on the Internet. Thus, services that should only be legitimately used by a relatively small number of hosts do not have to specifically deny access to unauthorized hosts. This sort of restriction helps prevent brute force authentication attacks (e.g. password guessing) and remote code injection exploits from untrusted hosts. | ||
# | # TCP wrappers work inside the application process, in userspace, while host-based firewalls block connections inside the kernel. | ||
# | # When a system is connected to a VPN, all of its network traffic is encrypted and sent to the VPN gateway. The gateway decrypts the traffic and sends it on to the intended destination. This also happens in reverse. You can verify this by examining the raw packets being received by and sent from the host's network device (ethernet, WiFi) using a program such as Wireshark and verifying that they are all going to or from the IP address of the VPN gateway and are encrypted. | ||
# | # VPNs can help defend against attackers that are "near" the VPN-connecting host, as such attackers can observe and manipulate network traffic. DNS redirects, IP spoofing, eavesdropping, and other attacks are all defended against by a VPN. The key limitation of VPNs is that they only protect traffic between the host and the VPN gateway; traffic can be intercepted and manipulated anywhere between the VPN gateway and the remote hosts that are being communicated with. To defend against network attacks end-to-end we need end-to-end encryption, authentication, and integrity protection. Such protection is provided by TLS. Note that VPNs provide protection for all traffic, not just TLS-protected - but only to and from the gateway. (Note VPNs don't on their own prevent compromised systems from connecting to a corporate network and infecting other systems. However, this challenge is not fundamental as VPNs aren't designed to solve this issue - it isn't part of their threat model. Other mechanisms, such as anti-malware scanners, can help protect against such threats.) | ||
# | # Carleton uses Cisco AnyConnect for VPN clients to connect to cuvpn.carleton.ca (which presumably is a Cisco VPN server). If you use this VPN server, you can access many restricted online paper respositories such as IEEE Xplore and ScienceDirect directly; otherwise, to access these you have to go through a web proxy provided by the Carleton Library. Also, you can access the SCS openstack cluster when connected to the campus VPN. |
Latest revision as of 00:03, 11 February 2018
Please answer the following questions. There are 13 questions with 20 points. Submit your answers as a text or PDF file via cuLearn by January 31, 2018 at 11:55 PM. Be sure to put your name and student number at the beginning of your submission.
When answering each question, please indicate the sources of your answer. This could be a man page, your own experiments, discussion with a friend, or a website. Please list all your sources. You are allowed to collaborate; such collaboration should be clearly documented! If you already know an answer because of background knowledge you had before the class, that is fine, just state that this is the case.
Questions
- [1] UNIX has users (UIDs) and groups (GIDs). From the kernel's perspective, users and groups are labels applied to what kernel-level abstractions?
- [2] UNIX file permissions are grouped into three categories, user, group, and other. Is it possible for the "other" category to have greater access to a file than the owner of a file? Explain with a brief example.
- [2] What is the difference between read and execute permission on a directory? How can you verify this is the case?
- [2] What is the "sticky bit"? What "attack" does the sticky bit prevent?
- [1] What are setuid root binaries?
- [1] Why are setuid root binaries important in most UNIX-like systems?
- [1] What is the risk of setuid root binaries? Be specific.
- [2] Briefly describe a potential vulnerability in a setuid root binary and how an attacker could exploit it.
- [1] TCP wrappers and host-based firewalls defend against similar threats. What type of threats do they protect against?
- [1] What is the key technical difference between how TCP wrappers and host-based firewalls work?
- [2] How does the behavior of your system change when you connect to a VPN? How can you verify that a VPN is working as it should?
- [2] How does a VPN improve the security of an organization? What is the fundamental limitation of a defense strategy organized around VPNs?
- [2] What VPN software does Carleton use? What is a specific (functional) benefit you can get when you use the Carleton VPN?
Solutions
- processes and files
- Yes, it is possible. For example, if we set the permissions of foo.txt to 066, then everyone except for the file owner will be able to read and write the file. (Of course, the owner can change these permissions at any time.)
- Read permission lets you list the files in a directory. Execute permission lets you open or execute a file named in the directory. You can verify this by setting only read or execute permissions with the chmod command (e.g., chmod a-r to remove read permissions, chmod a-x to remove execute permissions) and then seeing what access you have.
- Normally anyone who can write to a directory can also remove any file in the directory (as write privileges implies unlink privileges). If the sticky bit is set on such a directory with the command "chmod +t", however, users can only unlink their own files. Thus the sticky bit is normally set on system temporary file directories (e.g., /tmp, /var/tmp) and other world-writable directories.
- Setuid binaries have the setuid bit set (chmod u+s). This bit instructs the kernel to change the effective uid of the process after an execve to the owner of the exec'd binary. Setuid root binaries are binaries that are owned by root with the setuid bit set; thus, when they are run, they run with full root privileges.
- Setuid root binaries are important because they allow unprivileged users to perform privileged operations under controlled circumstances, such as changing their password or mounting a filesystem. Without setuid root binaries, the only way for a unprivileged user to perform a privileged operation on UNIX would be to communicate with a process that already had privileges (e.g., a privileged process listening on a socket).
- The risk of setuid root binaries is that 1) they can be run by unprivileged users and 2) they can perform privileged operations. If there is a flaw in such a binary, then unprivileged users can perform privileged tasks or even obtain full privileges when they shouldn't be able to. Thus, every setuid root binary represents an opportunity for an attacker to subvert the entire UNIX security model.
- There are many possible examples. A simple one is a passwd binary that doesn't properly restrict arbitrary password changes to the root user (e.g., there is a logic error in the code restricts arbitrary password changes to root). If this is the case, then any user can change anyone else's password.
- TCP wrappers and host-based firewalls prevent services from being accessed from arbitrary hosts on the Internet. Thus, services that should only be legitimately used by a relatively small number of hosts do not have to specifically deny access to unauthorized hosts. This sort of restriction helps prevent brute force authentication attacks (e.g. password guessing) and remote code injection exploits from untrusted hosts.
- TCP wrappers work inside the application process, in userspace, while host-based firewalls block connections inside the kernel.
- When a system is connected to a VPN, all of its network traffic is encrypted and sent to the VPN gateway. The gateway decrypts the traffic and sends it on to the intended destination. This also happens in reverse. You can verify this by examining the raw packets being received by and sent from the host's network device (ethernet, WiFi) using a program such as Wireshark and verifying that they are all going to or from the IP address of the VPN gateway and are encrypted.
- VPNs can help defend against attackers that are "near" the VPN-connecting host, as such attackers can observe and manipulate network traffic. DNS redirects, IP spoofing, eavesdropping, and other attacks are all defended against by a VPN. The key limitation of VPNs is that they only protect traffic between the host and the VPN gateway; traffic can be intercepted and manipulated anywhere between the VPN gateway and the remote hosts that are being communicated with. To defend against network attacks end-to-end we need end-to-end encryption, authentication, and integrity protection. Such protection is provided by TLS. Note that VPNs provide protection for all traffic, not just TLS-protected - but only to and from the gateway. (Note VPNs don't on their own prevent compromised systems from connecting to a corporate network and infecting other systems. However, this challenge is not fundamental as VPNs aren't designed to solve this issue - it isn't part of their threat model. Other mechanisms, such as anti-malware scanners, can help protect against such threats.)
- Carleton uses Cisco AnyConnect for VPN clients to connect to cuvpn.carleton.ca (which presumably is a Cisco VPN server). If you use this VPN server, you can access many restricted online paper respositories such as IEEE Xplore and ScienceDirect directly; otherwise, to access these you have to go through a web proxy provided by the Carleton Library. Also, you can access the SCS openstack cluster when connected to the campus VPN.