Difference between revisions of "SEC520/labs/Lab 7"

From CDOT Wiki
Jump to: navigation, search
Line 2: Line 2:
 
<h2> <span class="mw-headline">Introduction</span></h2>
 
<h2> <span class="mw-headline">Introduction</span></h2>
 
<dl><dd><ul><li>In the previous lab, we learned how to make our
 
<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.
+
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>
 
</li></ul>
 
</dd></dl>
 
</dd></dl>
 
<dl><dd><ul><li>In this lab, students will be learning about  
 
<dl><dd><ul><li>In this lab, students will be learning about  
"Authorization" within the <b>AAA</b> Protocol, to limit the resources or  
+
"Authorization" within the <b>AAA</b> Protocol, to limit the resources or  
applications that the system users are permitted to access. First,  
+
applications that the system users are permitted to access. First,  
students will use <b>ACLs</b> (Access Control Lists) to further define  
+
students will use <b>ACLs</b> (Access Control Lists) to further define  
authorization to groups of users within the organization.
+
authorization to groups of users within the organization.
 
</li></ul>
 
</li></ul>
 
</dd></dl>
 
</dd></dl>
 
<dl><dd><ul><li>Students will then learn how to install, configure and  
 
<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 <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  
+
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>.
+
<u>regular</u> or "elevated" user access to regular programs or utilities (administrative) by editing the <b>Sudoer's file</b>.
 
</li></ul>
 
</li></ul>
 
</dd></dl>
 
</dd></dl>
Line 24: Line 24:
 
<h2> <span class="mw-headline">Objectives</span></h2>
 
<h2> <span class="mw-headline">Objectives</span></h2>
 
<ol><li>Limit user access to files within defined groups using <b>Access Control Lists</b>.
 
<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>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>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><li>Control which user(s) can run <b>cron jobs</b> in order to run commands or programs on a scheduled basis.
 
</li></ol>
 
</li></ol>
 
<p><br>
 
<p><br>
Line 32: Line 32:
 
<h2> <span class="mw-headline">Required Materials (Bring to All Labs)</span></h2>
 
<h2> <span class="mw-headline">Required Materials (Bring to All Labs)</span></h2>
 
<ul>
 
<ul>
<li> <b>SATA Hard Disk</b> (in removable disk tray).
+
<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><li> <b>Lab Logbook (Lab5 Reference Sheet)</b> (to make notes and observations).
</li></ul>
+
</li></ul>
<p><br>
+
<p><br>
</p>
+
</p>
<h2> <span class="mw-headline">Prerequisites</span></h2>
+
<h2> <span class="mw-headline">Prerequisites</span></h2>
<ul><li> [https://wiki.cdot.senecacollege.ca/wiki/SEC520/labs/Lab_6 SEC520 Lab 6]
+
<ul><li> [https://wiki.cdot.senecacollege.ca/wiki/SEC520/labs/Lab_6 SEC520 Lab 6]
</li></ul>
+
</li></ul>
<p><br>
+
<p><br>
</p>
+
</p>
<h2> <span class="mw-headline">Online Tools and References</span></h2>
+
<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 &amp; 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>
 
<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>Boot-up your Kali Linux (host) and your <b>Hardened Linux VM</b> on your hard disk pack.</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>Log into your user account that has administrative priviledges (this should have been performed during installation process in lab4).</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>Open a shell terminal, and create the following directory: <b>~/share</b></li>
+
<li>Use the <b>getfacl</b> to confirm the permissions for the file: <b>~/share/project.txt</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>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>Use the <b>groupadd</b> command to create a new group name called <b>project</b> </li>
+
<li>Now switch (su) to another account. Can you make editing changes to <i>project.txt</i>? Why?.</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>Record your results in your lab log-book.</li>
<li>Use the touch command to create an empty file in the share directory called <b>~/share/project.txt</b> </li>
+
<li>Proceed to Task #2</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>
 
 
</ol>
 
</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 &amp; 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><b>Answer the Task #1 observations / questions in your lab log book.</b>
 
</p>
 
</p>
Line 114: Line 114:
  
 
<p><br><br/>
 
<p><br><br/>
 
+
INSTRUCTIONS:
+
INSTRUCTIONS:
{{Admon/important|SELinux Package|Confirm that the <b>SELinux</b> package is installed on your Linux VM.|}}
+
{{Admon/important|SELinux Package|Confirm that the <b>SELinux</b> package is installed on your Linux VM.|}}
<br />
+
<br />
</p><ol>
+
</p><ol>
<li>Familiarize yourself with the system-config-securitylevel tool  
+
<li>Familiarize yourself with the system-config-securitylevel tool  
(SELinux tab) and these SELinux commands (and SELinux-modified  
+
(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>
+
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>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>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>Restart Apache. Do not use apachectl  -- use the <b>service</b> command.</li>
<li>Create <b>~/public_html/index.html</b></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>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  
+
<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>
+
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>Put SELinux in <b>Permissive</b> mode.</li>
<li>Attempt to access the content you created in step 5 using a  
+
<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
+
browser. It should succeed. (If not, your <b>httpd.conf</b> file or permissions
are incorrect - fix them).</li>
+
are incorrect - fix them).</li>
<li>Put SELinux back into <b>Enforcing</b> mode.</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
+
<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  
+
make <b>~/public_html/index.html</b> accessible while SELinux is in Enforcing  
mode. Test it and make sure it works.</li>
+
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
+
<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 "Content-type: text/plain"
        echo
+
echo
        cal -y</pre></li>
+
cal -y</pre></li>
<li>Test your script through a web browser.</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
+
<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 "Content-type: text/plain"
        echo
+
echo
        echo "Attempting to show the contents of ~/.bash_profile:"
+
echo "Attempting to show the contents of ~/.bash_profile:"
        cat ~/.bash_profile
+
cat ~/.bash_profile
        if [ $? -eq 0 ]
+
if [ $? -eq 0 ]
        then
+
then
            echo "Success."
+
echo "Success."
        else
+
else
            echo "Failure."
+
echo "Failure."
        fi</pre></li>
+
fi</pre></li>
<li>Run this script via the web browser in both <b>Permissive</b> and  
+
<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  
+
<b>Enforcing</b> modes. Observe the difference in output. What is the reason  
for the difference?</li>
+
for the difference?</li>
<li>Record your findings in your lab log-book.</li>
+
<li>Record your findings in your lab log-book.</li>
<li>Proceed to Task #3</li>
+
<li>Proceed to Task #3</li>
</ol>
+
</ol>
  
 
<p><b>Answer Task #2 observations / questions in your lab log book.</b>
 
<p><b>Answer Task #2 observations / questions in your lab log book.</b>
</p><p><br>
+
</p><p><br>
 
</p>
 
</p>
  
Line 167: Line 167:
 
<h2> <span class="mw-headline">Task #3: Sudo</span></h2>
 
<h2> <span class="mw-headline">Task #3: Sudo</span></h2>
 
<br>
 
<br>
<i>"Sudo (switchuser/superuser do) allows a system administrator to give  
+
<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>
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>
 
<br><br>
 
INSTRUCTIONS:
 
INSTRUCTIONS:
 
<ol>
 
<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>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>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.  
+
<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.  
+
# 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.  
+
# See the sudoers man page for the details on how to write a sudoers file.  
#  
+
#  
 
+
# Host alias specification
+
# Host alias specification
Host_Alias MYHOST=localhost
+
Host_Alias MYHOST=localhost
# User alias specification
+
# User alias specification
 
+
<b>User_Alias USER3=user3
+
<b>User_Alias USER3=user3
# Cmnd alias specification
+
# Cmnd alias specification
Cmnd_Alias NETWORK=/sbin/ifconfig</b>
+
Cmnd_Alias NETWORK=/sbin/ifconfig</b>
 
+
Note: you NEED the ABSOLUTE path to the command you put in there.
+
Note: you NEED the ABSOLUTE path to the command you put in there.
 
+
# User privilege specification
+
# User privilege specification
root    ALL=(ALL) ALL
+
root    ALL=(ALL) ALL
<b>user3  ALL=NETWORK</b>
+
<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>
 
<br>
 
{{Admon/caution|Watch Syntax in Sudoers File|The sudoers file should  
 
{{Admon/caution|Watch Syntax in Sudoers File|The sudoers file should  
Line 209: Line 206:
 
file|}}
 
file|}}
 
<br>
 
<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 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;">
+
<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>
+
local1.*    /var/adm/sudo.log</pre><br /></li>
<li>Save your editing changes.</li>
+
<li>Save your editing changes.</li>
<li>Switch (su) as the third user (eg. in our demonstration: <b>user3</b>).</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>Experiment with the sudo capabilities assigned to the third user 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>Return to the administrator account.</li>
<li>Check the <b>/var/adm/sudo.log</b> file. What does it show ?</li>
+
<li>Check the <b>/var/adm/sudo.log</b> file. What does it show ?</li>
</ol>
+
 
  
 
<br>
 
<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>.
+
{{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>
 
<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 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>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
+
<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>
+
</pre>
<br>  
+
<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;">
+
</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
+
User_Alias USER1=user1
USER1 localhost.localdomain= PASSWD: /bin/kill</pre></li>
+
USER1 localhost.localdomain= PASSWD: /bin/kill</pre></li>
<li>Save changes to the sudoer's file and exit.</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) 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>
+
<li>Switch (su) to the third user, and execute the following command: <b>sudo -l</b>. What did this command do?</li>
</ol>
 
 
<br>
 
<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 '!'  
 
{{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.
 
elements in the user specification.
 
<br><br>
 
<br><br>
Running shell scripts via sudo can expose the same kernel bugs that make
+
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).
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>
 
<br><br>
 
(From sudo man page)|}}
 
(From sudo man page)|}}
 
<br>
 
<br>
 
+
<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>
<ol>
+
<b>!id</b><br><br></li>
<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>
+
<li>What was the id of the third user and what what sort of implications does this create in terms of system security?</li>
<b>!id</b><br><br></li>
+
<li>Record your findings in your lab log-book.</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>Proceed to Task #4.</li>
<li>Record your findings in your lab log-book.</li>
 
<li>Proceed to Task #4.</li>
 
 
</ol>
 
</ol>
  
 
<p><b>Answer Task #3 observations / questions in your lab log book.</b>
 
<p><b>Answer Task #3 observations / questions in your lab log book.</b>
</p><p><br>
+
</p><p><br>
 
</p>
 
</p>
  
Line 271: Line 262:
 
INSTRUCTIONS:
 
INSTRUCTIONS:
 
<ol>
 
<ol>
<li>Switch to the super-user, and issue the following command: <br /><b>crontab -u user1 -e</b><br /></li>
+
<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 &gt;&gt; ~/uptime.txt'
+
<li>Add the following contents into the first user's <b>crontab</b> file:<br><br><pre style="font-family:courier,monospace;">  * * * * * 'uptime &gt;&gt; ~/uptime.txt'
</pre></li>
+
</pre></li>
<li>Save and exit your crontab editing session.</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>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 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>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>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>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>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>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>
+
<li>Proceed to "Completing The Lab".</li>
 
</ol>
 
</ol>
  
 
<p><b>Answer Task #4 observations / questions in your lab log book.</b>
 
<p><b>Answer Task #4 observations / questions in your lab log book.</b>
</p><p><br>
+
</p><p><br>
 
</p>
 
</p>
  
Line 294: Line 285:
 
</p>
 
</p>
 
<ol>
 
<ol>
<li>Compare ACLs by demonstrating running services via <b>user1</b> and <b>user2</b>.</li>
+
<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>Verify SELinux is running in <b>Enforcing</b> mode.</li>
<li>Display contents of <b>sudoer's file (for user1)</b>.</li>
+
<li>Display contents of <b>sudoer's file (for user1)</b>.</li>
<li>Verification of running <b>crob job</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>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>
+
<li>Completed Lab 7 notes.</li>
 
</ol>
 
</ol>
 
<p><br>
 
<p><br>
Line 306: Line 297:
  
 
<ol>
 
<ol>
<li>What does the term <b>ACL</b> stand for?</li>
+
<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>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>ACLs</b>?</li>
<li>What is the purpose of <b>SELinux</b>.</li>
+
<li>What is the purpose of <b>SELinux</b>.</li>
<li>List the various modes 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 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 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>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 perform a software update.</li>
<li>Write a Linux command to set the Linux server to text-based mode.</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>
+
<li>Why is it recommended to run a Linux server in text-based mode?</li>
 
</ol>
 
</ol>

Revision as of 10:08, 1 February 2018

Linux System Hardening (part 2)

Introduction

  • 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.
  • In this lab, students will be learning about "Authorization" within the AAA Protocol, to limit the resources or applications that the system users are permitted to access. First, students will use ACLs (Access Control Lists) to further define authorization to groups of users within the organization.
  • Students will then learn how to install, configure and run SELinux which provides limitations of which users are entitled to run processes within the server. Students will then learn how to limit regular or "elevated" user access to regular programs or utilities (administrative) by editing the Sudoer's file.
  • Finally, students will complete the "lock down" of the computer system by learning how to limit the running of scheduled processes (cron jobs), perform software upgrades, and to turn-off X-windows on a Linux server.



Objectives

  1. Limit user access to files within defined groups using Access Control Lists.
  2. Install, configure, and run SELinux which is used to enforce entitled users access to running processes.
  3. Configure the sudoer's file in order to allow other users access to linux commands that are only considered for administrators.
  4. Control which user(s) can run cron jobs in order to run commands or programs on a scheduled basis.


Required Materials (Bring to All Labs)

  • SATA Hard Disk (in removable disk tray).
  • Lab Logbook (Lab5 Reference Sheet) (to make notes and observations).


Prerequisites


Online Tools and References


Course Notes

  • odp | pdf | ppt (Slides: Linux System Hardening - part 2)


Performing Lab 7

Task #1: ACLs


In this section, students will learn how to use ACLs (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.

INSTRUCTIONS:

  1. Boot-up your Kali Linux (host) and your Hardened Linux VM on your hard disk pack.
  2. Log into your user account that has administrative priviledges (this should have been performed during installation process in lab4).
  3. Open a shell terminal, and create the following directory: ~/share
  4. Set passthrough permissions for your home directory, and set permissions to allow same group members access and view the contents of the share directory. Use the ls -ld command to confirm the set permissions for these directories.
  5. Use the groupadd command to create a new group name called project
  6. Use the usermod command to add the three users (created in lab4) to the group called project. View the contents of the /etc/group file to confirm that the users have been added to the project group.
  7. Use the touch command to create an empty file in the share directory called ~/share/project.txt
  8. Use the chgrp command to have the file project.txt belong to the project group. Use the ls -l command to confirm that the project.txt file now belongs to the project group.
  9. Set permissions for same group members to view and modify contents of the file ~/share/project.txt and confirm that the permissions have been correctly set for that file.
  10. Switch (i.e. su) to one of the users (added to the project group), and confirm that they can access and modify the file: ~/share/project.txt
  11. Repeat the above step for the second user (belonging to the project group).
  12. Why can you allow the first user to both read and modify 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.


  13. Important.png
    ACL Package
    An ACL or Access Control List 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.


  14. Switch (su) back to your administration account.
  15. Issue the following command: rpm -qi acl to confirm that the acl application has been installed in your system. If it is not present, make certain to install that application.
  16. In order to use ACLs, you need to edit the /etc/fstab file to mount all disk filesystems with the acl option
    (Refer to the following link for an example: Mounting With ACL Option).
  17. Issue the command: mount -o remount /
    in order to remount your file system (as opposed to rebooting).

  18. Important.png
    Missing acl option in listed Mounts
    Usually, it is a good idea to confirm that the acl option is present from the remount by viewing either the /etc/fstab or /etc/mtab files. If you are using Fedora17, it may not appear, although it is active. This may be attributed to a bug...


  19. View the Youtube video (or other online resources) on how to use ACLs: Video
  20. Set same group members for group name project to only view the contents of the file ~/share/project.txt
  21. Use the setfacl command to allow only one of the users to both view and modify the file ~/share/project.txt

    For example, if the username is user1, then issue the command:

    setfacl -m u:user1:rw share/project.txt

  22. Use the getfacl to confirm the permissions for the file: ~/share/project.txt
  23. Switch (su) to your account that you used the setfacl command to provide read/write permissions. Can you make editing changes to project.txt?
  24. Now switch (su) to another account. Can you make editing changes to project.txt? Why?.
  25. Record your results in your lab log-book.
  26. Proceed to Task #2

Answer the Task #1 observations / questions in your lab log book.



Task #2: SELinux



INSTRUCTIONS:

Important.png
SELinux Package
Confirm that the SELinux package is installed on your Linux VM.


  1. Familiarize yourself with the system-config-securitylevel tool (SELinux tab) and these SELinux commands (and SELinux-modified commands):
    • getenforce, setenforce
    • getsebool, setsebool
    • chcon
    • restorecon
    • ls -Z, ps -Z, id
    • gnome-system-monitor
    • system-config-securitylevel

  2. Ensure that your SELinux system is in enforcing mode.
  3. Configure Apache to permit the use of $HOME/public_html directories by editing the httpd.conf file:
    • Comment out the UserDir Disable directive.
    • Uncomment the UserDir public_html directive.
    • Uncomment the directory container for /home/*/public_html and configure it permit the execution of CGI scripts.
    • Uncomment the directive add_handler cgi-script .cgi

  4. Restart Apache. Do not use apachectl -- use the service command.
  5. Create ~/public_html/index.html
  6. Attempt to access the content you created in step 5 using a browser. It should fail.
  7. Review the latest avc messages in /var/log/messages and compare them to the Apache error log. Record your finding in your lab log-book.
  8. Put SELinux in Permissive mode.
  9. Attempt to access the content you created in step 5 using a browser. It should succeed. (If not, your httpd.conf file or permissions are incorrect - fix them).
  10. Put SELinux back into Enforcing mode.
  11. Using the man page for httpd_selinux, determine what is required to make ~/public_html/index.html accessible while SELinux is in Enforcing mode. Test it and make sure it works.
  12. Create the following Bash shell script (called test.bash):
             #!/bin/bash
    		echo "Content-type: text/plain"
    		echo
    	cal -y
  13. Test your script through a web browser.
  14. Create the following testing CGI script (called test.cgi):
             #!/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
  15. Run this script via the web browser in both Permissive and Enforcing modes. Observe the difference in output. What is the reason for the difference?
  16. Record your findings in your lab log-book.
  17. Proceed to Task #3

Answer Task #2 observations / questions in your lab log book.



Task #3: Sudo


"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."

INSTRUCTIONS:

  1. READ the man page on sudo and visudo. Most modern versions of Linux have sudo default installed.
  2. Open sudoers using visudo.
  3. We will be setting up logging information as well as allowing the third user to issue certain administrative commands. With the setup below, this lab is making reference to username: user3 (replace this with the actual username of the third user). Make the following changes to the sudoer's file, adding information that appears in bold:

    # 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>
    		
    	

  4. Stop (medium size).png
    Watch Syntax in Sudoers File
    The sudoers file should

    always be edited by the visudo command which locks the file and does grammatical checking. It is imperative that sudoers be free of syntax errors since sudo will not run with a syntactically incorrect sudoers

    file


  5. Save and exit the visudo editing session. Check and return to editing session if any errors are created.
  6. Edit the file /etc/rsyslog.conf and add the following line to the bottom of this file (for logging purposes):

    	local1.*    /var/adm/sudo.log

  7. Save your editing changes.
  8. Switch (su) as the third user (eg. in our demonstration: user3).
  9. Experiment with the sudo capabilities assigned to the third user by issuing the command: sudo /sbin/ifconfig eth0 (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.
  10. Return to the administrator account.
  11. Check the /var/adm/sudo.log file. What does it show ?


  12. Stop (medium size).png
    No Entries in /var/adm/sudo.log File
    If you do not see any entries in the /var/adm/sudo.log file, then shutdown, and then restart your Hardened Linux VM, and repeat steps 7 to 10.



  13. Switch (su) to a different user (other than your third user), and try to issue the sudo /sbin/ifconfig eth0 command. What happenned?
  14. Switch (su) to the administrator's account, and view the contents of /var/adm/sudo.log. What do you notice?
  15. Edit the sudoers file and add the following line (where hostname is your VM machine):
    USER3 localhost.localdomain= NOPASSWD: /bin/kill, PASSWD: /bin/ls, /usr/bin/lprm
    	


  16. While in edit mode, add USER1 as an alias for user1, and add the kill command to the Cmnd_Aliases line for user1. Each line should appear similar to this:
    		User_Alias USER1=user1
    	USER1 localhost.localdomain= PASSWD: /bin/kill
  17. Save changes to the sudoer's file and exit.
  18. 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. user1) and attempt to kill another process. Where you prompted to enter a password?
  19. Switch (su) to the third user, and execute the following command: sudo -l. What did this command do?

  20. Important.png
    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 ALL, 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.

    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 /dev/fd directory, setuid shell scripts are generally safe).

    (From sudo man page)


  21. Grant vi privileges to the third user. Switch (su) as the third user and issue the command: sudo vi. Press : to go to the last line mode in your vi text editor, and issue the command:

    !id

  22. What was the id of the third user and what what sort of implications does this create in terms of system security?
  23. Record your findings in your lab log-book.
  24. Proceed to Task #4.

Answer Task #3 observations / questions in your lab log book.


Task #4: Cron Jobs & Turning off XWindows


This last section involves "tweaks" to harden your Linux system from less obvious vulnerabilities. First, you will learn as the adiminstrator to limit cron jobs (i.e. scheduled tasks) that can be run by users. Finally, you will change from run level 5 (Xwindows) to level 3 (text-based) to make your system less vulnerable to attacks.

INSTRUCTIONS:

  1. Switch to the super-user, and issue the following command:
    crontab -u user1 -e
  2. Add the following contents into the first user's crontab file:

      * * * * * 'uptime >> ~/uptime.txt'
    	
  3. Save and exit your crontab editing session.
  4. Edit the /etc/crontab.allow 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.
  5. Login to the first user and see if your cron job is working.
  6. Login to the second user (created in lab4) to see if that account can create a cron job. Where you successful? Why?
  7. 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.
  8. Perform another software update (either graphically or using the yum or apt-get commands). Verify that the software upgrades are up-to-date.
  9. Switch your Linux server from graphical mode (eg run level 5) to default mode (eg run level 3). Note: The procedure has changed in newer Linux system (using sysd). Refer to the following link to learn how to set your Fedora17 system to text-based mode: Init vs Systemd
  10. Perform a scan from your Kali Linux (host) machine to hopefully see a more hardened system with less running services.
  11. Proceed to "Completing The Lab".

Answer Task #4 observations / questions in your lab log book.


Completing the Lab

Arrange evidence for each of these items on your screen, then ask your instructor to review them and sign off on the lab's completion:

  1. Compare ACLs by demonstrating running services via user1 and user2.
  2. Verify SELinux is running in Enforcing mode.
  3. Display contents of sudoer's file (for user1).
  4. Verification of running crob job.
  5. Linux system in text-based mode (i.e. run level 3 for your Hardened Linux system).
  6. Completed Lab 7 notes.


Preparing for Quizzes

  1. What does the term ACL stand for?
  2. Compare and contrast the features of ACLs for Windows (using NTFS) and Linux.
  3. What is the purpose of ACLs?
  4. What is the purpose of SELinux.
  5. List the various modes of SELinux.
  6. Briefly list the steps to allow the regular user called msaul to run administrative commands.
  7. Briefly explain how to setup the sudoer's file to have the user ctyler only run the administrative command: visudo
  8. Briefly list the steps to allow user1 to run a cron job called cleanup.bash
  9. Write a Linux command to perform a software update.
  10. Write a Linux command to set the Linux server to text-based mode.
  11. Why is it recommended to run a Linux server in text-based mode?