Chapter 18. Local System Security

Objectives

• Assess system security risks
• Fashion and implementation of security policies and procedures
• Efficiency protect BIOS and the boot loader with passwords
• Use appropiate mount options, setuid and setgid to enhance security

Creating a security policy

The characteristics of a security policy

• Be simple and easy to understand
• Get constantly updated
• Be in the form of a written document 
• Describe both policies and procedures
• Specify enforcement actions
• Specify actions to take in response to a security breach

What to include in the policy

• Confidentiality
• Data Integrity
• Availability
• Consistency
• Control
• Audit

What risks to assess

• What do I want to protect?
• What am I protecting it against?
• How much time, money and personnel is needed to provide adequate protectio?

Choose a Security Philosophy

• Anything not expressly permitted is denied
• Anything not expressly forbidden is permitted

Some General Security Guidelines

• Human factor is the weakest link
• No computing environment is invulnerable
• Paranoia is a good thing

Updates and Security

• Do not dealy the implementation of security patches from the linux distributions

Hardware Accessibility and Vulnerability​

Anytime a hardware is physically accessible security risks are

• Key logging
• Network sniffing
• Booting with a live or secure disk
• Remounting and modifying disk content

Hardware access guidelines

• Locking down workstations and servers
• Protect network links against not trusted people
• Protecting keyboards where passwords are entered to ensure the keyboards cannot be tempered with
• Configure password protection of the BIOS such that the system can not be booted with a live CD/DVD or USB 

Protection of BIOS

• Is the lowest level of security
• Should be protected by use of a password
• Should be updated and current

Protecting the Boot Loader with Passwords

• GRUB version 1
  • Invoke grub-md5-crypt
    • Will ask for a password, then encrypt it and display it
  • Edit /boot/grub/grub.conf
    • Set the password given by grub-md5-crypt like this
      • password --md5 $1$Wnvo.1$qz781HRVG4jUnJXmdSCZ30

Filesystem Security: mount Options

When mounting a filesystem several parameters can be used to improve security

• nodev
  • Do not interpret character or block special devices on the filesystem
• nosuid
  • The set-user-identifier or set-group-identifier bits are not to take effect
• noexec
  • Restrict direct execution of any binaries on the mounted filesystem
• ro
  • Mount the filesystem as read-only mode as in

    • $ mount -o ro,noexec,nodev /dev/sda2 /mymountpt
      

    • or in /etc/fstab

    • /dev/sda2 /mymountpt  ext4 ro,noexec,nodev 0 0

setuid and setgid

In order to allow a given binary to run with owner privileges or group privileges instead of the currenty user (that is executing the binary) priviledges, we can use 

• setuid
  • Setting this flag on the executable will allow such file to run with owner privileges
• setgid
  • Setting this flag on the executable will allow such file to run with group privileges

Setting setuid or setgid flags

To files this is simply done by 

$ chmod u+s somefile

$ chmod g+s somefile

​To folders such command has different implication

​$ chmod g+s somedirectory

​Means that files created in such directory are group owned by the group owner of the directory.

Note: We can not effectively change the setuid on a shell script file, in order to do this (to have the .sh running with owner privileges) we have to change the setuid bit of the shell program itself, which is a really bad idea.

LAB 18.1

We are going to mount a partition or loop device with the noexec option to prevent execution of programs that reside on the filesystem therein. You can certainly do this with a pre-existing and mounted partition, but you may not be able to easily change the behavior while the partition is mounted. Therefore, to demonstrate we’ll use a loop device, which is a harmless procedure.

1. Set up an empty file, put a filesystem on it and mount it.
2. Copy an executeble file to it from somewhere else on your system and test that it works in the new location.
3. Unmount it and remount with the noexec option.
4. Test if the executable still works. It should give you an error because of the noexec mount option.
5. Clean up. 

Solution

1. Set up an empty file, put a filesystem on it and mount it.

$ dd if=/dev/zero of=image bs=1M count=100 $ sudo mkfs.ext3 image
$ mkdir mountpoint
$ sudo mount -o loop image mountpoint

2. Copy an executeble file to it from somewhere else on your system and test that it works in the new location.

$ sudo cp /bin/ls mountpoint
​$ mountpoint/ls

3. Unmount it and remount with the noexec option.

​$ sudo umount mountpoint
$ sudo mount -o noexec,loop image mountpoint

or

$ sudo mount -o noexec,remount image mountpoint

4. Test if the executable still works. It should give you an error because of the noexec mount option.

$ mountpoint/ls

5. Clean up. 

$ sudo umount mountpoint
$ rm image
$ rmdir mountpoint

Note that this is not persistent. To make it persistent you would need to add the option to /etc/fstab with a line like:

/home/student/image /home/student/mountpoint ext3 loop,rw,noexec 0 0 

Lab 18.2: More on setuid and Scripts

Suppose we have the following C program (./writeit.c) which attempts to overwrite a file in the current directory named afile:

#include <stdio.h>
#include <unistd.h>
#include <fcntl.h>
#include <stdlib.h>
#include <string.h>
#include <stdlib.h>
#include <sys/stat.h>
int main(int argc, char *argv[])
{
        int fd, rc;
        char *buffer = "TESTING A WRITE";
        fd = open("./afile", O_RDWR | O_CREAT | O_TRUNC, S_IRUSR | S_IWUSR);
        rc = write(fd, buffer, strlen(buffer));
        printf("wrote %d bytes\n", rc);
        close(fd);
        exit(EXIT_SUCCESS);
}

If you are taking the online self-paced version of this course, the source code is available for download from your Lab screen.

If the program is called writeit.c, it can be compiled simply by doing:

$ make writeit

or equivalently

$ gcc -o writeit writeit.c

If (as a normal user) you try to run this program on a file owned by root you’ll get

$ sudo touch afile
$ ./writeit

wrote -1 bytes

but if you run it as root:

$ sudo ./writeit

wrote 15 bytes

Thus, the root user was able to overwrite the file it owned, but a normal user could not. Note that changing the owner of writeit to root does not help: 

$ sudo chown root.root writeit
$ ./writeit
wrote -1 bytes

because it still will not let you clobber afile.
By setting the setuid bit you can make any normal user capable of doing it:

$ sudo chmod +s writeit
$ ./writeit
wrote 15 bytes

You may be asking, why didn’t we just write a script to do such an operation, rather than to write and compile an executable program?

Under Linux, if you change the setuid on such an executable script, it won’t do anything unless you actually change the setuid bit on the shell (such as bash) which would be a big mistake; anything running from then on would have escalated privilege!