feat: a3

.gitignore

@@ -2,3 +2,5 @@
 sheet01/a2/Hash.java
 *.class
 passwd
+sheet04/AuthWithTOTP.java
+sheet04/key-exchange.pcap

sheet05/a1/archive.sh

@@ -0,0 +1,3 @@
+#!/bin/bash
+# $1 = directory path
+chmod -R a-w "$1"

sheet05/a1/create_user.sh

@@ -0,0 +1,3 @@
+#!/bin/bash
+# $1 = username, $2 = comma-separated groups
+useradd -G "$2" "$1" || usermod -aG "$2" "$1"

sheet05/a1/explanation.txt

@@ -0,0 +1,6 @@
+UNIX permissions only support one Owner, one Group, and Other (UGO). 
+The 'Group' slot is already taken by the specific lecture group to give students write access.
+If we use 'Other' to give the supervisor read access, every user on the system could read it, which would violate the requirements.
+If we add the supervisor to the lecture group, they get write access, which also violates the requirements.
+
+Because a file cannot have multiple groups or user-specific overrides under standard UNIX permissions, this cannot be solved.

sheet05/a1/supervisor.sh

@@ -0,0 +1,3 @@
+#!/bin/bash
+# $1 = supervisor username
+echo "not possible with the standard UNIX permissions. See explanation.txt."

sheet05/a2/archive.sh

@@ -0,0 +1,3 @@
+#!/bin/bash
+TARGET_DIR=$1
+chmod -R a-w "$TARGET_DIR"

sheet05/a2/create_user.sh

@@ -0,0 +1,4 @@
+#!/bin/bash
+USERNAME=$1
+GROUPS=$2
+useradd -G "$GROUPS" "$USERNAME" || usermod -aG "$GROUPS" "$USERNAME"

sheet05/a2/explanation.txt

@@ -0,0 +1,3 @@
+The supervisor's read access would fail with UNIX permissions, since they are limited to one owner, one group, and "others". 
+Access Control Lists (ACLs) resolve this problem by allowing permissions beyond the standard three. 
+Using `setfacl`, we can append specific read and execute rights (r-x) for individual users (the supervisors) directly to the files and directories.

sheet05/a2/supervisor.sh

@@ -0,0 +1,6 @@
+#!/bin/bash
+SUPERVISOR=$1
+# Grant read and execute permissions to the supervisor user recursively
+setfacl -R -m u:"$SUPERVISOR":r-x .
+# Set the default ACL
+setfacl -R -d -m u:"$SUPERVISOR":r-x .

sheet05/a3/a.txt

@@ -0,0 +1,4 @@
+Passwords are stored in the /etc/shadow file, which is restricted to the root user. 
+A standard user cannot write to it directly. However, the passwd executable is owned by root and has the SUID permission set. 
+When a standard user runs passwd, the SUID bit tells the system to execute the program with the privileges of root, 
+giving the program the temporary permissions to update /etc/shadow

sheet05/a3/b.txt

@@ -0,0 +1,5 @@
+The script runs with root privileges because the setuid bit is set. 
+Since it just asks for a username and saves the new hash to /etc/shadow, 
+and there is no validation checking if the user running the program is actually changing their own password, 
+someone could simply run the program, type root as the username, and set a new password for the root user. 
+The script would then overwrite the actual root password in /etc/shadow.