<h2> <span class="mw-headline">Introduction</span></h2>
<dl><dd><ul><li>In the previous lab, we learned how to make our
Linux server less vulnerable by setting a grub password, preventing unneccessary services from running, tunnelling with SSH, and using PAM modules for setting authentication rules when running user applications. Although this is useful, vulnerability can exist when running the few essential services.
</li></ul>
</dd></dl>
<dl><dd><ul><li>In this lab, students will be learning about
"Authorization" within the <b>AAA</b> Protocol, to limit the resources or applications that the system users are permitted to access. First, students will use <b>ACLs</b> (Access Control Lists) to further define authorization to groups of users within the organization.
</li></ul>
</dd></dl>
<dl><dd><ul><li>Students will then learn how to install, configure and
run <b>SELinux</b> which provides limitations of which users are <u>entitled</u> to run processes within the server. Students will then learn how to limit <u>regular</u> or "elevated" user access to regular programs or utilities (administrative) by editing the <b>Sudoer's file</b>.
</li></ul>
</dd></dl>
<h2> <span class="mw-headline">Objectives</span></h2>
<ol><li>Limit user access to files within defined groups using <b>Access Control Lists</b>.
</li><li>Install, configure, and run <b>SELinux</b> which is used to enforce <u>entitled</u> users access to running processes. </li><li>Configure the <b>sudoer's file</b> in order to allow other users access to linux commands that are only considered for administrators. </li><li>Control which user(s) can run <b>cron jobs</b> in order to run commands or programs on a scheduled basis.
</li></ol>
<p><br>
<h2> <span class="mw-headline">Required Materials (Bring to All Labs)</span></h2>
<ul>
<li> <b>SATA Hard Disk</b> (in removable disk tray). </li><li> <b>Lab Logbook (Lab5 Reference Sheet)</b> (to make notes and observations). </li></ul> <p><br> </p> <h2> <span class="mw-headline">Prerequisites</span></h2> <ul><li> [https://wiki.cdot.senecacollege.ca/wiki/SEC520/labs/Lab_6 SEC520 Lab 6] </li></ul> <p><br> </p> <h2> <span class="mw-headline">Online Tools and References</span></h2> <ul> <li>[http://www.yolinux.com/TUTORIALS/LinuxTutorialManagingGroups.html#ACL ACLs]</li>[http://www.yolinux.com/TUTORIALS/LinuxTutorialManagingGroups.html#ACL ]<li>[http://hackinglinux.blogspot.ca/2007/05/selinux-tutorial.html SELinux]</li> <!--DEAD LINK<li>[http://www.syntaxtechnology.com/2009/06/sudo-tutorial/ Sudo]</li>--> <li>[http://cs.senecac.on.ca/%7Efac/ops435/2008_dev/ops435_w11_l1.pdf Cron Jobs]</li> </ul> <p><br> </p> <h2> <span class="mw-headline">Course Notes</span></h2> <ul> <li>[http://cs.senecac.on.ca/%7Efac/sec520/slides/sec520_w4_l1.odp odp] | [http://cs.senecac.on.ca/%7Efac/sec520/slides/sec520_w4_l1.pdf pdf] | [http://cs.senecac.on.ca/%7Efac/sec520/slides/sec520_w4_l1.ppt ppt] (Slides: Linux System Hardening - part 2)</li> <!--DEAD LINK<li>[http://lcweb.senecac.on.ca:2063/0596003919 Linux Security Cookbook (E-book)] (Chapter 5)</li>--> <!--DEAD LINK<li>[http://lcweb.senecac.on.ca:2063/0131963694?uicode=seneca Linux By Example (E-book)] (Chapter x)</li>--> </ul> <p><br> </p> <h1> <span class="mw-headline">Performing Lab 7</span></h1> <h2> <span class="mw-headline">Task #1: ACLs</span></h2> <br> In this section, students will learn how to use <b>ACLs</b> (Access Control Lists) to "finely-tune" group access to directories and files, and differentiate between setting permissions via ACL and setting permissions using the chmod command. <br><br> INSTRUCTIONS: <br> <ol> <li>Boot-up your Kali Linux (host) and your <b>Hardened Linux VM</b> on your hard disk pack.</li> <li>Log into your user account that has administrative priviledges (this should have been performed during installation process in lab4).</li> <li>Open a shell terminal, and create the following directory: <b>~/share</b></li> <li>Set passthrough permissions for your home directory, and set permissions to allow same group members access and view the contents of the <b>share</b> directory. Use the <b>ls -ld</b> command to confirm the set permissions for these directories.</li> <li>Use the <b>groupadd</b> command to create a new group name called <b>project</b> </li> <li>Use the <b>usermod</b> command to add the three users (created in lab4) to the group called <b>project</b>. View the contents of the <b>/etc/group</b> file to confirm that the users have been added to the <i>project</i> group.</li> <li>Use the touch command to create an empty file in the share directory called <b>~/share/project.txt</b> </li> <li>Use the <b>chgrp</b> command to have the file <b>project.txt</b> belong to the <b>project</b> group. Use the <b>ls -l</b> command to confirm that the <i>project.txt</i> file now belongs to the <i>project</i> group.</li> <li>Set permissions for same group members to <u>view</u> and <u>modify</u> contents of the file <b>~/share/project.txt</b> and confirm that the permissions have been correctly set for that file.</li> <li>Switch (i.e. su) to one of the users (added to the <i>project</i> group), and confirm that they can access and modify the file: <b>~/share/project.txt</b></li> <li>Repeat the above step for the second user (belonging to the <i>project</i> group).</li> <li>Why can you allow the first user to both <u>read</u> and <u>modify</u> the project.txt file, but you can't only allow the second user to only read the project.txt file without editing permissions? Answer in your lab log-book.</li> <br> {{Admon/important|ACL Package|An <b>ACL</b> or <b>Access Control List</b> is a system that sets permissions to specific objects, as oppposed to general directories and files. This allows more flexibility when granting read, read & write permissions for different users for the same file or directory.<br /><br />|}} <br> <li value="13">Switch (su) back to your administration account.</li> <li>Issue the following command: <b>rpm -qi acl</b> to confirm that the <b>acl</b> application has been installed in your system. If it is not present, make certain to install that application.</li> <li>In order to use <b>ACLs</b>, you need to edit the <b>/etc/fstab</b> file to mount all disk filesystems with the <b>acl option</b><br />(Refer to the following link for an example: [http://www.yolinux.com/TUTORIALS/LinuxTutorialManagingGroups.html#ACL Mounting With ACL Option]).</li> <li>Issue the command: <b>mount -o remount /</b> <br />in order to remount your file system (as opposed to rebooting).</li>
<ul>
<li>[http://www.yolinux.com/TUTORIALS/LinuxTutorialManagingGroups.html#ACL ACLs]</li>[http://www.yolinux.com/TUTORIALS/LinuxTutorialManagingGroups.html#ACL
]<li>[http://hackinglinux.blogspot.ca/2007/05/selinux-tutorial.html SELinux]</li>
<!--DEAD LINK<li>[http://www.syntaxtechnology.com/2009/06/sudo-tutorial/ Sudo]</li>-->
<li>[http://cs.senecac.on.ca/%7Efac/ops435/2008_dev/ops435_w11_l1.pdf Cron Jobs]</li>
</ul>
<p><br>
</p>
<h2> <span class="mw-headline">Course Notes</span></h2>
<ul>
<li>[http://cs.senecac.on.ca/%7Efac/sec520/slides/sec520_w4_l1.odp odp] | [http://cs.senecac.on.ca/%7Efac/sec520/slides/sec520_w4_l1.pdf pdf] | [http://cs.senecac.on.ca/%7Efac/sec520/slides/sec520_w4_l1.ppt ppt] (Slides: Linux System Hardening - part 2)</li>
<!--DEAD LINK<li>[http://lcweb.senecac.on.ca:2063/0596003919 Linux Security Cookbook (E-book)] (Chapter 5)</li>-->
<!--DEAD LINK<li>[http://lcweb.senecac.on.ca:2063/0131963694?uicode=seneca Linux By Example (E-book)] (Chapter x)</li>-->
</ul>
<p><br>
</p>
<h1> <span class="mw-headline">Performing Lab 7</span></h1>
<h2> <span class="mw-headline">Task #1: ACLs</span></h2>
<br>
In this section, students will learn how to use <b>ACLs</b> (Access Control Lists) to "finely-tune" group access to directories and files, and differentiate between setting permissions via ACL and setting permissions using the chmod command.
<br><br>
INSTRUCTIONS:
<br>
{{Admon/important|Missing acl option in listed Mounts|Usually, it is a good idea to confirm that the <b>acl</b> option is present from the remount by viewing either the <b>/etc/fstab</b> or <b>/etc/mtab</b> files. If you are using Fedora17, it may not appear, although it is active. This may be attributed to a bug...<br /><br />|}}
<br />
<ol> <livalue="17">Boot-up your Kali Linux View the Youtube video (hostor other online resources) and your <b>Hardened Linux VM<on how to use ACLs: [http://b> on your hard disk packwww.</li> <li>Log into your user account that has administrative priviledges (this should have been performed during installation process in lab4)youtube.<com/li> <li>Open a shell terminal, and create the following directory: <b>~/share</b>watch?v=6piQXXHTmqk Video]</li> <li>Set passthrough permissions for your home directory, and set permissions to allow same group members access and view the contents of the for group name <b>shareproject</b> directory. Use the to only <bu>ls -ldview</bu> command to confirm the set permissions for these directories.</li> <li>Use contents of the file <b>groupadd<~/share/b> command to create a new group name called <b>project.txt</b> </li> <li>Use the <b>usermodsetfacl</b> command to add the three users (created in lab4) to the group called allow only <bu>projectone</bu>. View the contents of the <b>/etc/group</b> file to confirm that the users have been added to the both <iu>projectview</iu> group.and </liu> modify<li/u>Use the touch command to create an empty file in the share directory called <b>~/share/project.txt</b> <br /li> <libr >Use For example, if the username is <b>chgrpuser1</b> , then issue the command to have the file <b>project.txt:<br /b> belong to the <b>project<br /b> group. Use the <b>ls setfacl -l<m u:user1:rw share/b> command to confirm that the <i>project.txt</ib> file now belongs to the <ibr />project<br /i> group.</li> <li>Set permissions for same group members to Use the <ub>viewgetfacl</ub> and <u>modify</u> contents of to confirm the permissions for the file : <b>~/share/project.txt</b> and confirm that the permissions have been correctly set for that file.</li> <li>Switch (i.e. su) to one of the users (added to your account that you used the <ib>projectsetfacl</ib> group), and confirm that they can access and modify the file: command to provide read/write permissions. Can you make editing changes to <bi>~/share/project.txt</bi>?</li> <li>Repeat the above step for the second user Now switch (belonging su) to another account. Can you make editing changes to the <i>project.txt</i> group)? Why?.</li> <li>Why can you allow the first user to both <u>read</u> and <u>modify</u> the project.txt file, but you can't only allow the second user to only read the project.txt file without editing permissions? Answer Record your results in your lab log-book.</li> <li>Proceed to Task #2</li>
</ol>
<br>
{{Admon/important|ACL Package|An <b>ACL</b> or <b>Access Control List</b> is a system that sets permissions to specific objects, as oppposed to general directories and files. This allows more flexibility when granting read, read & write permissions for different users for the same file or directory.<br /><br />|}}
<br>
<ol>
<li value="13">Switch (su) back to your administration account.</li>
<li>Issue the following command: <b>rpm -qi acl</b> to confirm that the <b>acl</b> application has been installed in your system. If it is not present, make certain to install that application.</li>
<li>In order to use <b>ACLs</b>, you need to edit the </b><b>/etc/fstab</b></b> file to mount all disk filesystems with the <b>acl option</b><br />(Refer to the following link for an example: [http://www.yolinux.com/TUTORIALS/LinuxTutorialManagingGroups.html#ACL Mounting With ACL Option]).</li>
<li>Issue the command: <b>mount -o remount /</b> <br />in order to remount your file system (as opposed to rebooting).</li>
</ol>
<br>
{{Admon/important|Missing acl option in listed Mounts|Usually, it is a good idea to confirm that the <b>acl</b> option is present from the remount by viewing either the <b>/etc/fstab</b> or <b>/etc/mtab</b> files. If you are using Fedora17, it may not appear, although it is active. This may be attributed to a bug...<br /><br />|}}
<br />
<ol>
<li value="17">View the Youtube video (or other online resources) on how to use ACLs: [http://www.youtube.com/watch?v=6piQXXHTmqk Video]</li>
<li>Set same group members for group name <b>project</b> to only <u>view</u> the contents of the file <b>~/share/project.txt</b>
</li><li>Use the <b>setfacl</b> command to allow only <u>one</u> of the users to both <u>view</u> and <u>modify</u> the file <b>~/share/project.txt</b><br /><br >For example, if the username is <b>user1</b>, then issue the command:<br /><br /><b>setfacl -m u:user1:rw share/project.txt</b><br /><br /></li>
<li>Use the <b>getfacl</b> to confirm the permissions for the file: <b>~/share/project.txt</b></li>
<li>Switch (su) to your account that you used the <b>setfacl</b> command to provide read/write permissions. Can you make editing changes to <i>project.txt</i>?</li>
<li>Now switch (su) to another account. Can you make editing changes to <i>project.txt</i>? Why?.</li>
<li>Record your results in your lab log-book.</li>
<li>Proceed to Task #2</li>
</ol>
<p><b>Answer the Task #1 observations / questions in your lab log book.</b>
</p>
<p><br><br/>
INSTRUCTIONS: {{Admon/important|SELinux Package|Confirm that the <b>SELinux</b> package is installed on your Linux VM.|}} <br /> </p><ol> <li>Familiarize yourself with the system-config-securitylevel tool (SELinux tab) and these SELinux commands (and SELinux-modified commands):<ul style="font-family:courier,monospace;"><li>getenforce, setenforce</li><li>getsebool, setsebool</li><li>chcon</li><li>restorecon</li><li>ls -Z, ps -Z, id</li><li>gnome-system-monitor</li><li>system-config-securitylevel<br><br></li></ul></li> <li>Ensure that your SELinux system is in <b>enforcing</b> mode.</li> <li>Configure Apache to permit the use of <b>$HOME/public_html</b> directories by editing the <b>httpd.conf</b> file:<ul><li>Comment out the <b>UserDir Disable</b> directive.</li><li>Uncomment the <b>UserDir public_html</b> directive.</li><li>Uncomment the directory container for <b>/home/*/public_html</b> and configure it permit the execution of CGI scripts.</li><li>Uncomment the directive <b>add_handler cgi-script .cgi</b><br><br></li></ul></li> <li>Restart Apache. Do not use apachectl -- use the <b>service</b> command.</li> <li>Create <b>~/public_html/index.html</b></li> <li>Attempt to access the content you created in step 5 using a browser. It should fail.</li> <li>Review the latest avc messages in <b>/var/log/messages</b> and compare them to the Apache error log. Record your finding in your lab log-book.</li> <li>Put SELinux in <b>Permissive</b> mode.</li> <li>Attempt to access the content you created in step 5 using a browser. It should succeed. (If not, your <b>httpd.conf</b> file or permissions are incorrect - fix them).</li> <li>Put SELinux back into <b>Enforcing</b> mode.</li> <li>Using the man page for <b>httpd_selinux</b>, determine what is required to make <b>~/public_html/index.html</b> accessible while SELinux is in Enforcing mode. Test it and make sure it works.</li> <li>Create the following Bash shell script (called <b>test.bash</b>):<br><pre style="font-family:courier,monosplace;"> #!/bin/bash echo "Content-type: text/plain" echo cal -y</pre></li> <li>Test your script through a web browser.</li> <li>Create the following testing CGI script (called <b>test.cgi</b>):<br><pre style="font-family:courier,monosplace;"> #!/bin/bash echo "Content-type: text/plain" echo echo "Attempting to show the contents of ~/.bash_profile:" cat ~/.bash_profile if [ $? -eq 0 ] then echo "Success." else echo "Failure." fi</pre></li> <li>Run this script via the web browser in both <b>Permissive</b> and <b>Enforcing</b> modes. Observe the difference in output. What is the reason for the difference?</li> <li>Record your findings in your lab log-book.</li> <li>Proceed to Task #3</li> </ol>
<p><b>Answer Task #2 observations / questions in your lab log book.</b>
</p><p><br>
</p>
<h2> <span class="mw-headline">Task #3: Sudo</span></h2>
<br>
<i>"Sudo (switchuser/superuser do) allows a system administrator to give certain users (or groups of users) the ability to run some (or all) commands as root while logging all commands and arguments. Sudo operates on a per-command basis, it is not a replacement for the shell."</i>
<br><br>
INSTRUCTIONS:
<ol>
<li>READ the man page on <b>sudo</b> and <b>visudo</b>. Most modern versions of Linux have sudo default installed.</li> <li>Open sudoers using <b>visudo</b>.</li> <li>We will be <b>setting up logging information</b> as well as allowing the <b>third user to issue certain administrative commands</b>. With the setup below, this lab is making reference to username: <b>user3</b> (replace this with the actual username of the third user). Make the following changes to the <b>sudoer's file</b>, adding information that appears in <b>bold</b>:<br><br><pre style="font-family:courier,monospace;"># sudoers file. # # This file MUST be edited with the 'visudo' command as root. # # See the sudoers man page for the details on how to write a sudoers file. # # Host alias specification Host_Alias MYHOST=localhost # User alias specification <b>User_Alias USER3=user3 # Cmnd alias specification Cmnd_Alias NETWORK=/sbin/ifconfig</b> Note: you NEED the ABSOLUTE path to the command you put in there. # User privilege specification root ALL=(ALL) ALL <b>user3 ALL=NETWORK</b> # Defaults Specification <b>Defaults syslog=local1</b> </pre></li>
# Defaults Specification
<b>Defaults syslog=local1</b>
</pre></li>
</ol>
<br>
{{Admon/caution|Watch Syntax in Sudoers File|The sudoers file should
file|}}
<br>
<ol> <li value="4">Save and exit the visudo editing session. Check and return to editing session if any errors are created.</li> <li>Edit the file <b>/etc/rsyslog.conf</b> and add the following line to the bottom of this file (for logging purposes):<br /><br /><pre style="font-family:courier,monospace;"> local1.* /var/adm/sudo.log</pre><br /></li> <li>Save your editing changes.</li> <li>Switch (su) as the third user (eg. in our demonstration: <b>user3</b>).</li> <li>Experiment with the sudo capabilities assigned to the third user</b> by issuing the command: <b>sudo /sbin/ifconfig eth0</b> (You'll have to supply the user password). For the purpose of this lab, the command does not have to work - don't worry about error messages.</li> <li>Return to the administrator account.</li> <li>Check the <b>/var/adm/sudo.log</b> file. What does it show ?</li></ol>
<br>
{{Admon/caution|No Entries in /var/adm/sudo.log File|If you do not see any entries in the </b>/var/adm/sudo.log</b> file, then shutdown, and then restart your Hardened Linux VM, and <u>repeat</u> <b>steps 7 to 10</b>.
|}}
<br>
<ol> <li value="11">Switch (su) to a different user (other than your third user), and try to issue the <b>sudo /sbin/ifconfig eth0</b> command. What happenned?</li> <li>Switch (su) to the administrator's account, and view the contents of <b>/var/adm/sudo.log</b>. What do you notice?</li> <li>Edit the sudoers file and add the following line (where hostname is your VM machine):<pre style="font-family:courier,monospace;">USER3 localhost.localdomain= NOPASSWD: /bin/kill, PASSWD: /bin/ls, /usr/bin/lprm </pre> <br> </li><li>While in edit mode, add <b>USER1</b> as an alias for user1, and add the <b>kill</b> command to the <b>Cmnd_Aliases</b> line for <b>user1</b>. Each line should appear similar to this:<pre style="font-family:courier,monospace;"> User_Alias USER1=user1 USER1 localhost.localdomain= PASSWD: /bin/kill</pre></li> <li>Save changes to the sudoer's file and exit.</li> <li>Switch (su) as the third user and attempt to kill a process. Where you prompted to enter a password? Then switch (su) as the first user (eg. <b>user1</b>) and attempt to kill another process. Where you prompted to enter a password? </li> <li>Switch (su) to the third user, and execute the following command: <b>sudo -l</b>. What did this command do?</li></ol>
<br>
{{Admon/important|Vulnerability with Sudo (vi)|There is no easy way to prevent a user from gaining a root shell if that user has access to commands allowing shell escapes. If users have sudo <b>ALL</b>, there is nothing to prevent them from creating their own program that gives them a root shell regardless of any '!'
elements in the user specification.
<br><br>
Running shell scripts via sudo can expose the same kernel bugs that make setuid shell scripts unsafe on some operating systems (if your OS supports the <b>/dev/fd</b> directory, setuid shell scripts are generally safe).
<br><br>
(From sudo man page)|}}
<br>
<ol> <li value="18">Grant <b>vi</b> privileges to the third user. Switch (su) as the third user and issue the command: <b>sudo vi</b>. Press : to go to the <b>last line mode</b> in your vi text editor, and issue the command:<br><br> <b>!id</b><br><br></li> <li>What was the id of the third user and what what sort of implications does this create in terms of system security?</li> <li>Record your findings in your lab log-book.</li> <li>Proceed to Task #4.</li>
</ol>
<p><b>Answer Task #3 observations / questions in your lab log book.</b>
</p><p><br>
</p>
INSTRUCTIONS:
<ol>
<li>Switch to the super-user, and issue the following command: <br /><b>crontab -u user1 -e</b><br /></li> <li>Add the following contents into the first user's <b>crontab</b> file:<br><br><pre style="font-family:courier,monospace;"> * * * * * 'uptime >> ~/uptime.txt' </pre></li> <li>Save and exit your crontab editing session.</li> <li>Edit the <b>/etc/crontab.allow</b> file to include the first user. If the file does not exist, simply create it, or check with the Linux distribution for instructions to use the crontab.allow file.</li> <li>Login to the first user and see if your cron job is working.</li> <li>Login to the second user (created in lab4) to see if that account can create a cron job. Where you successful? Why?</li> <li>Try to list at least 3 types of Bash Shell scripts that a Linux system administrator can limit to specific users. Record your findings in your lab log-book.</li> <li>Perform another software update (either graphically or using the <b>yum</b> or <b>apt-get</b> commands). Verify that the software upgrades are up-to-date.</li> <li>Switch your Linux server from graphical mode (eg run level 5) to default mode (eg run level 3). <b>Note:</b> The procedure has changed in newer Linux system (using <b>sysd</b>). Refer to the following link to learn how to set your Fedora17 system to text-based mode: [http://zenit.senecac.on.ca/wiki/index.php/Init_vs_systemd Init vs Systemd]</li> <li>Perform a scan from your Kali Linux (host) machine to hopefully see a more hardened system with less running services.</li> <li>Proceed to "Completing The Lab".</li>
</ol>
<p><b>Answer Task #4 observations / questions in your lab log book.</b>
</p><p><br>
</p>
</p>
<ol>
<li>Compare ACLs by demonstrating running services via <b>user1</b> and <b>user2</b>.</li> <li>Verify SELinux is running in <b>Enforcing</b> mode.</li> <li>Display contents of <b>sudoer's file (for user1)</b>.</li> <li>Verification of running <b>crob job</b>.</li> <li>Linux system in <b>text-based mode</b> (i.e. run level 3 for your <b>Hardened Linux</b> system).</li> <li>Completed Lab 7 notes.</li>
</ol>
<p><br>
<ol>
<li>What does the term <b>ACL</b> stand for?</li> <li>Compare and contrast the features of ACLs for Windows (using NTFS) and Linux.</li> <li>What is the purpose of <b>ACLs</b>?</li> <li>What is the purpose of <b>SELinux</b>.</li> <li>List the various modes of <b>SELinux</b>.</li> <li>Briefly list the steps to allow the regular user called <b>msaul</b> to run administrative commands.</li> <li>Briefly explain how to setup the sudoer's file to have the user <b>ctyler</b> only run the administrative command: <b>visudo</b></li> <li>Briefly list the steps to allow <b>user1</b> to run a <b>cron job</b> called <b>cleanup.bash</b></li> <li>Write a Linux command to perform a software update.</li> <li>Write a Linux command to set the Linux server to text-based mode.</li> <li>Why is it recommended to run a Linux server in text-based mode?</li>
</ol>