COMP 3000 2021F Assignment 3 Solutions 1. [2] Download and inspect 3000makefs.sh. Is there a risk of data loss from running this script? Specifically, what commands (if any) are potentially dangerous? A: There is a big risk of data loss, especially as the script demands you run it as root. There are rm commands for the IMAGE and MP directories. There are also many cp commands that could overwrite existing files. While the current version of the script seems safe enough, minor changes could change that drastically! (In particular, don't change MP to be "/"!) 2. [1] Run 3000makefs.sh. After 3000makefs.sh runs, you're put in a new shell where / is now the contents of 3000fs, and you can't see anything that wasn't in 3000fs. Exiting the shell gets you back to where you were. After exiting, how do you get back to the modified environment? A: To get back, you just have to run "sudo chroot 3000fs". (Note that we did a "cd 3000fs" and then "chroot ." at the end of the script.) 3. [2] Lines 55-59 of 3000makefs.sh is several echo commands. What are these lines doing? Do these lines relate to any other parts of the script? A: These echo commands are to create a shell script (run by busybox) to initialize the filesystem, creating symlinks for busybox commands, updating the dynamic linker cache, and mounting /proc and /dev. The following two lines make this file executable (chmod) and then run the script after doing a chroot. The rm command then gets rid of the script. 4. [2] What are lines 26-30 for? Is it missing anything? Explain briefly. A: These lines are to get rid of the existing directory at the mountpoint (3000fs). Since we've mounted directories there, we have to unmount them first before we can remove the mountpoint. These commands aren't complete, we should also be unmounting /dev; if we don't, the script won't be able to clean up properly from a previous run if we run it more than once. 5. [2] What is the largest file we can create in the confined environment (once initialized by 3000makefs.sh)? What determines this limit? A: Immediately after running 3000makefs.sh, the largest file you can make is 364077056 bytes (347.2M). This size is determined by the size of the filesystem we created, which in turn is determined by the number of bytes we wrote with the dd command (100,000 * 4K). (If you did some things in the filesystem before creating a big file, or if you ran this on a different Linux distribution, you may get a value smaller than this, depending on what you did. But for this question you should have started with a frest environment.) To find this value you can either create a file, say by running dd from /dev/zero or /dev/urandom, or you can just run df. (Note that filesystems can reserve some space for the root user, and this reserved space isn't marked as available by df. It is okay if you just report the amount that df says is available.) 6. [2] If you create files in the confined environment, does it reduce the space available outside of it? How do you know? A: Yes it does, because when we did the mkfs.ext4 it created holes in the filesystem image file, thus reducing how much space it took up. Thus every time we write data to the confined environment the space occupied by the filesystem will increase up until it reaches the logical size of the filesystem image file. We can verify this by running "ls -s" and noticing whe block count of the image file keeps growing as we write data in the confined filesystem. 7. [2] Many files in our confined environment are symbolic links. How did these files get created? Why are they symbolic links and not regular files? Explain their purpose. A: These symbolic links were created by the "busybox --install -s" command that was executed from the SETUP script. Busybox does this so it can take on the functionality of many standard UNIX utilities. They are symbolic links because we used the -s option; without it, busybox would have created hard links. 8. [2] Copy and make nano work in the new environment. What files did you have to copy to get it to work? How did you know to copy them? A: You have to copy /lib/x86_64-linux-gnu/libncursesw.so.6 to /lib in the confined environment. You can see this by copying nano into the environment and trying to run it, it reports that it can't find this file. You could also use the command sudo cp `ldd /usr/bin/nano | awk '{print $3}'` 3000fs but this will copy all of the dependencies, and only libncursesw.so.6 is new. 9. [3] How can you add a user "confined" to 3000fs? Make sure the user also is in a new group "confined" and has a home directory /home/confined (in 3000fs). This user should only be visible when you're in 3000fs's special shell. (If you run id when you regularly log in as student to your VM, there should be no user confined.) Make sure you can run "login confined" and be logged in as the user confined (as verified by whoami). Confirm this by running whoami. A: To add a user, we need to make a new home directory for the user and make changes to four files in /etc: passwd, shadow, group, gshadow. We could edit these files manually, but we can also just use the adduser command in the regular environment. To do this, do the following in the unconfined system: # become root sudo -i # change to the 3000fs directory cd /path/to/3000fs # backup account files mkdir /BACKUP cp -a /etc/passwd /etc/group /etc/shadow /etc/gshadow /BACKUP # create the new user, giving it the password and other info you want adduser confined # move confined's home directory mv /home/confined home # add the last line of each of the account files to the confined # account files. (Could also just copy the files over, but in # general we shouldn't assume the confined system will have the same # accounts as the main system.) for x in passwd shadow group gshadow; do L=`tail -1 /etc/$x` echo Adding the following to $x: echo $L echo $L >> etc/$x echo done # restore backup files and delete them cp -a /BACKUP/* /etc rm -rf /BACKUP When I ran the above I got the following: ----------- Adding the following to passwd: confined:x:1002:1002:Confined User,,,:/home/confined:/bin/bash Adding the following to shadow: confined:$6$IWggtEOxCbsGuThn$cVQVRNWEG4LDydaHZ5c01.rBb0/tsPSEo2dmCoxjkIsnc5/m9wK5rOHYGwrD96fRZoJK2doPllV3EEVYuvZRb.:18951:0:99999:7::: Adding the following to group: confined:x:1002: Adding the following to gshadow: confined:!:: ----------- 10. [2] How can you mount the main root filesystem inside of the confined environment? What does this say about the security properties of a chroot'd environment? A: First, in the main root filesystem run df to find out its device. You'll get output something like this: student@comp3000:~$ df . Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/vg0-lv--0 8187320 4471888 3279824 58% / In the chroot'd environment we can then mount it as follows: bash-5.1# mkdir /mainfs bash-5.1# mount /dev/mapper/vg0-lv--0 /mainfs After this, /mainfs will contain all of the system's files. A weird consequence of this is how Linux avoids duplicate vies of the confined files. For example, if we ran 3000makefs.sh in /home/student/Documents/A3, we'd see the following when just logging in: student@comp3000:~$ ls /home/student/Documents/A3 3000fs 3000fsimage 3000makefs.sh student@comp3000:~$ ls /home/student/Documents/A3/3000fs bin etc lib linuxrc mainfs root sbin tmp var dev home lib64 lost+found proc run sys usr However, if we look at the same paths after running chroot, things look a bit different than we might expect: bash-5.1# ls / bin home linuxrc proc sbin usr dev lib lost+found root sys var etc lib64 mainfs run tmp bash-5.1# ls /mainfs/home/student/Documents/A3/3000fs bash-5.1# ls /mainfs/home/student/Documents/A3 3000fs 3000fsimage 3000makefs.sh Note how 3000fs appears to be empty while A3 shows the files we would expect. 11. '''[4 EC]''' Make sshd work inside of the confined environment, listening in on port 2222. You should be able to ssh via localhost into the confined environment. (Outside access probably won't be possible due to restrictions on openstack. Note that I haven't gotten this working yet!)