CITS3007 lab 3 (week 4) – Permissions and setuid programs – solutions

The commands all have their setuid bit set. This is needed because:

• For chsh, it changes a user’s login shell, and that information is stored in /etc/passwd, which is only writeable by root. (In other words – the reason is much the same as for passwd.)

or,

• For su and sudo: they allow commands to be run with root permissions.

If you copy one of the setuid programs, the copy no longer has its setuid bit set. By default, the cp command assumes we wish to copy the file content, but not file properties like whether the setuid bit is set.³

Even if you do set the setuid bit on the files, using chmod, though – due to the way they have been coded, none of the programs will function properly without both (a) having the setuid bit set, and (b) being owned by root.

This is a safety precaution built into the programs: if the programs detect they are being used in a way that isn’t intended, they abort execution.

This is not in line with best practice.

Our hr_db_amend program will run as root, when it could be given far fewer privileges, which would lessen the impact if we happen to make a mistake when coding it.

A better approach would be, for instance, to create a user called hr, and have that user ID own the database file /var/hr/hr.db and the hr_db_amend executable.

We could still make our program setuid; but now it would run as user hr, giving it access to the HR database, but not to important system configuration files like /etc/passwd and /etc/shadow.

An example of a Unix program which creates specialized user accounts, just for the purpose of reading or writing files owned by those accounts, is crontab, part of the “cron” software package.

Crontab allows users to create recurring “tasks” which will be run periodically on a Unix system. The files defining these tasks are stored in the directory /var/spool/cron/crontabs. The Crontab program needs to meet the following requirements:

• Individual non-root users should be able to create configuration files in the /var/spool/cron/crontabs directory; BUT
• Individual users should also have the integrity and confidentiality of their files protected – which means we can’t simply make /var/spool/cron/crontabs world-readable and writable.

The solution is to make the /var/spool/cron/crontabs directory group-owned by a group called crontab, and for the /usr/bin/crontab program to be a setgid program and be also group-owned by crontab.⁵ (setgid is like setuid, but it means a program runs with different group permissions, instead of different user permissions.)

By listing the details of /var/spool/cron/crontabs and /usr/bin/crontab, you should be able to confirm that this is the case.

Because of the security vulnerabilities often introduced by setuid and setgid programs, a blog post by Konstantin Ivanov here suggests removing (or partly disabling) many of the less commonly used setuid and setgid programs – they introduce potential vulnerabilities for little advantage.

The getuid() and geteuid() functions cannot fail, but setresuid() can.

This is documented in the manual pages for those functions.

It does contain security flaws. The setuid function (or seteuid, a variant of it found on many Unix-like operating systems) can fail, and if it fails, then we haven’t successfully relinquished privileges. In case of a failure, we must immediately abort execution – otherwise, we’ll be performing actions which were intended to be performed by a non-privileged user, but will be performing them as root. This is highly prone to being exploited by attackers.

We should check the return value from setuid, and if it is non-zero, we should abort.

(In fact, we should always check the return value from any function call that can fail. All our subsequent code has presumably been written on the assumption that the function call succeeded; if it didn’t, then our assumption is wrong, and we have no idea what the actual current state of the system is.)

Yes, it’s possible to create a symbolic link (“symlink”, for short) to a symbolic link in Unix-like operating systems. You can verify this just by trying it out: create a file (say, “somefile.txt”), create a symlink to it (for instance, with the command ln -s somefile.txt mylink), and then create a symlink to that symlink.

Creating a symlink to a symlink just adds an extra level of indirection.

You can experiment by creating a file yourself (e.g. by running the command “echo 'foo' > file_a”), creating a symlink to that file (e.g. by running the command “ln -s file_a file_b”), and then listing and attempting to alter the permissions of file_b.

If you try this, and display the permissions of file_b (by, for instance, running ls -al), you should see an entry like the following:

  lrwxrwxrwx  1 vagrant vagrant     6 Mar 11 01:54 file_b -> file_a

The symlink is listed as granting all permissions to all users; and if you try changing the permissions, you’ll see that what you end up doing is actually changing the permissions of the target file (file_a).

The reason for this is that symbolic links are treated specially by the operating system – the permissions lrwxrwxrwx are the only permissions a symlink can ever have.

We can change the owner and group-owner of a symbolic link, distinct from its target, but (a) it’s a little tricky to do so, and (b) it will have no effect on which users can read or write from the target file.

If we trying invoking the chown command on a symlink, then by default, it will change the ownership of the target file, not the link. This is explained in the man page for the chown command, man chown, which says that we can pass the options --dereference and --no-dereference to chown. The first option is also the default behaviour, and means that we’ll actually be changing ownership of the target. The second option, --no-dereference, is needed if we want to change ownership of the symlink itself.

However, if you do so (e.g. by running “sudo chown --no-dereference root:root file_b”), you’ll discover that it makes no difference to who can read or write the file. That’s determined by the owner (and group) of the target file.

One way of finding out the filesystem type is to use the df command (see man df), which is normally used for showing disk space usage. If you pass the options “-T” or “--print-type” to df, it will show not just how much space is in use on each file system, but what the filesystem type is for each of them.

Running the command “df -hT” within the CITS3007 SDE will produce output similar to the following:

vagrant@cits3007-ubuntu2004:~$ df -hT
Filesystem     Type      Size  Used Avail Use% Mounted on
udev           devtmpfs  193M     0  193M   0% /dev
tmpfs          tmpfs      48M  940K   47M   2% /run
/dev/vda3      ext4      124G  5.1G  112G   5% /
tmpfs          tmpfs     237M     0  237M   0% /dev/shm
tmpfs          tmpfs     5.0M     0  5.0M   0% /run/lock
tmpfs          tmpfs     237M     0  237M   0% /sys/fs/cgroup
/dev/vda1      ext4      456M  202M  220M  48% /boot
tmpfs          tmpfs      48M     0   48M   0% /run/user/1000

The filesystem type for the root partion “/” is shown to be “ext4” – this is a member of the “EXT” (“EXTended File System”) family of filesystems which are common on Linux systems.

There are many other ways for displaying a filesystem’s type besides using df. If we know the device file that represents the root partition (/dev/vda3, from the listing above), we can show its filesystem type using the blkid command (“locate/print block device attributes”) – see man blkid. Running blkid on the CITS3007 SDE will produce output like the following:

vagrant@cits3007-ubuntu2004:~$ blkid
/dev/vda1: UUID="a69580c8-ef0b-49b8-b6de-9e4d72d3ea10" TYPE="ext4" PARTUUID="a1614753-01"
/dev/vda2: UUID="41ca73ed-c076-41a1-88c4-9f3f6b2233ac" TYPE="swap" PARTUUID="a1614753-02"
/dev/vda3: UUID="61ca90f5-3323-4d55-a8ee-c1dd2a72f267" TYPE="ext4" PARTUUID="a1614753-03"

Running the mount command will also display the filesystem type of all mounted filesystems.

Modern versions of Windows do support symbolic links (see the Wikipedia page on “Symbolic link”).

To use symbolic links, they have to be supported by both the filesystem, and the operating system – whether you can create a symbolic link on a USB thumb drive would depend on what filesystem the drive has been formatted with, and what operating system (and version) you are accessing it with.

Many thumb drives use a variants on a simple filesystem called FAT (short for “File Allocation Table”), originally developed in 1977. FAT is also sometimes used for the boot partition of desktop computers. FAT does not support symbolic links, so typically, you can’t create a symlink on a thumb drive, even if you have it mounted to a Unix operating system (you’ll typically get an “Operation not permitted” error, if you try it). Some thumb drives instead use a Microsoft-designed filesystem called NTFS, modern versions of which do support symbolic links.

The Windows OS has supported symbolic links since version 6.0 (Windows Vista, released in 2007).

The exact answer will depend on your operating system and version. If it is Linux, we have covered the answer already.

On Windows, passwords are stored as part of the registry, in a database file called the Security Account Manager, and the exact algorithm used for hashing varies from version to version of Windows – at the time of writing, an NTLM hash is typical.

On MacOS, the location of password hashes varies from version to version, but
as of version 10.7, they are in /var/db/dslocal/nodes/Default/users/${USER}.plist (where USER is a user ID), and the hash function used is PBKDF2-HMAC-SHA512. You can read more about how MacOS password hashes can be encrypted and broken here. (Note that if experimenting with password cracking, you must only do so with your own passwords and on your own computer – it is illegal and unethical to use other people’s data or computers without permission.)

The following is a sample solution for the would_wrap_around() function:

/** Return true when the sum of dirlen, filelen, extlen and 3
 * would exceed the maximum possible value of a size_t; otherwise,
 * return false.
 */
bool would_wrap_around(size_t dirlen, size_t filelen, size_t extlen) {
  size_t res = dirlen;
  res += filelen;
  if (res < dirlen || res < filelen)
    return true;
  size_t old_res = res;
  res += extlen;
  if (res < old_res || res < extlen)
    return true;
  old_res = res;
  res += 3;
  if (res < old_res || res < extlen)
    return true;
  return false;
}

Comments on the code:

• This can be simplified somewhat. In line 8, for instance, we check to see if the result of dirlen + filelen is less than dirlen or less than filelen. But actually, it suffices to see if the result is less than dirlen alone. (Can you see why?)

The following is a sample solution for the make_pathname() function:

char* make_pathname(const char *dir, const char *fname, const char *ext) {
  size_t dirlen = strlen(dir);
  size_t filelen = strlen(fname);
  size_t extlen = strlen(ext);

  if (would_wrap_around(dirlen, filelen, extlen)
    return NULL;

  // include terminating NUL
  size_t pathbuf_size = dirlen + filelen + extlen + 3;

  char *path = malloc (pathbuf_size);
  if (!path)
      return NULL;

  memcpy (path, dir, dirlen);
  path[dirlen] = '/';

  memcpy (path + dirlen + 1, fname, filelen);
  path[dirlen + filelen + 1] = '.';

  memcpy(path + dirlen + filelen + 2, ext, extlen + 1);

  return path;
}

Some comments on the code:

• When working on a C project, it can be helpful if your development team has a convention for distinguishing lengths of strings (which don’t include in their count the terminating NUL) from sizes of buffers (which always should include in their count any required NUL characters).

  This can help make code reviews easier, and ensure mistakes aren’t made by using one sort of length where the other would be appropriate. (Even better would be to configure your team’s static analysis programs to distinguish the two, and enforce rules about how each is used.)

  The code above uses names like dirlen, filelen etc for string lengths, but pathbuf_size for a buffer.

• When you submit C code as part of an assessment, your code will be assessed not only for correctness, but for style and clarity.

  This means making appropriate use of C library functions. The following are examples of solutions which don’t make appropriate use of C library functions:

  1. Solutions which don’t make use of C library functions at all – for instance, using a for loop instead of memcpy to copy characters from the arguments to path:

       for(size_t i = 0; i < dirlen; i++){
               path[i] = dir[i];
       }

     Writing a for loop makes the solution needlessly complex, harder to read than necessary, and more prone to error. If a known number of bytes need to be copied from one location in memory to another, then memcpy is the standard C idiom for doing so.

  2. Solutions which use strcat to build up the path instead of memcpy.

     For instance:

     strcpy(path, dir);
     strcat(path, "/");
     strcat(path, fname);
     strcat(path, ".");
     strcat(path, ext);

     Although less problematic than the code in point (a), this is needlessly inefficient. Each call to strcat will result in path being iterated over again.

  3. Solutions which use snprintf to write into path – these are creating additional points of failure in the function. They are discussed further below.

Calling make_pathname

We could write a main routine which allows us to invoke make_pathname from the command-line, as follows:

int main(int argc, char **argv) {
  // skip program name
  argc--;
  argv++;

  if (argc != 3) {
    fprintf(stderr, "Expected 3 args\n");
    exit(EXIT_FAILURE);
  }

  // See note: poor validation!
  char* dir = argv[0];
  char* fname = argv[1];
  char* ext = argv[2];

  char* path = make_pathname(dir, fname, ext);

  if (path != NULL) {
    printf("path is: '%s'\n", path);
    free(path);
  }
  else
    printf("couldn't allocate enough memory\n");

  return EXIT_SUCCESS;
}

Some comments on the code:

• In lines 12–14, our program is taking input from a potentially untrusted user via the elements of the argv array.

  We can be sure that those elements are valid null-terminated strings – they aren’t NULL pointers, nor do they run off past the end of the memory segment – because the language standard assures us so.

  But we can’t be sure they satisfy the other preconditions of make_pathname (e.g. the file and extension not containing slashes or dots).

  So that will mean that when we call make_pathname, we could be violating its preconditions, and the returned string might not be what we expect and might not be safe to use.

  Furthermore, if we pass that string on to other functions, we can render ourselves vulnerable to a path traversal attack (see https://owasp.org/www-community/attacks/Path_Traversal).

  For instance, suppose the dir argument is known to be a (system-controlled, trusted) path to a directory where web pages are stored (“/path/to/webdir”, say), and the fname and ext arguments are taken from an (untrusted) browser request and specify an HTML file to serve up.

  If we haven’t validated the contents of the fname and ext arguments, an attacker could set them to "." and "/", respectively. Then the result of make_pathname would be “/path/to/webdir/../”, which represents the parent directory of webdir.

  We have thus potentially given the attacker the ability to read files from outside the directory they should have access to, which could include configuration files and other sensitive data.

  We will look in more detail at input validation and path traversal attacks in future labs.

An alternative implementation of make_pathname:

char* make_pathname(const char* dir, const char* fname, const char* ext) {
  if (would_wrap_around(dirlen, filelen, extlen)
    return NULL;

  size_t totalLength = strlen(dir) + strlen(fname) + strlen(ext) + 3;
  // +3 for '/', '.', and '\0'

  char* result = malloc(totalLength);
  if (result == NULL)
    return NULL;

  int written = snprintf(result, totalLength, "%s/%s.%s", dir, fname, ext);
  if (written != totalLength - 1) {
    free(result);
    return NULL; // error occurred
  }

  return result;
}

Comments on this implementation:

• This implementation uses snprintf – many C programmers would regard memcpy and array-element assignment as the simpler solution, though, because when called correctly, memcpy can’t fail. (memcpy is basically just a for loop which copies from destination to source.)

  snprintf on the other hand is a complicated function. There’s no obvious reason why it should fail, if our logic is correct; but nevertheless, we can only be certain that it worked if the number of bytes written was exactly equal to what we expected (totalLength - 1). So we’ve added in an additional possibility for failure that wasn’t in the original specification – the spec said we would only return NULL if it wasn’t possible to allocate enough memory, but now we’re opening up the possibility for other causes of error.

  (Technically, if we’re failing for some reason other than “can’t allocate enough memory”, we should probably abort() rather than return NULL, because we can’t fulfil the promise we made in the function specification.)

In current versions of Linux (since at least kernel version 3.0), it’s not (straightforwardly) possible for a Python program to be setuid. You can try it by writing the following Python program, and making it owned by root, executable, and with its setuid bit enabled:

#!/usr/bin/env python3

import os

euid = os.geteuid()
print("euid is:", euid)

When run, this script will simply print out your normal user ID, not 0.

Why is this? One reason is that the file is a script, and isn’t being executed in the same way as a binary executable. When asked to execute a program, the kernel inspects the start of a file to determine what sort of program it is being asked to run.⁷

The first 4 bytes of a binary executable on Linux will be "\0x7fELF", indicating that it’s an ELF-format executable, but scripts will start with the characters "#!", indicating that they are intended to be supplied to an interpreter to be run – in the case of Python scripts, the interpreter will end up being /usr/bin/python3.

So for Python scripts, the machine-code instructions which are loaded into memory and executed by the processor don’t come from the script (they couldn’t – the script contains plain text, not machine code), but from the Python interpreter binary executable at /usr/bin/python3. That file doesn’t have its setuid bit enabled, so it doesn’t run as root. (The script file is just a data file which the Python interpreter opens, reads, and interprets as Python instructions.)

You could deliberately set the Python interpreter to be a setuid program, if you wanted; but that would be very unwise, as now all Python programs would run as root.

Is there any other way one could run a Python script as a setuid program? Yes, there is: you could create a custom interpreter designed to run Python scripts that have their setuid bit enabled. Your interpreter would need to be owned by root and be a setuid program itself, and scripts intended to be run by it would start with #!/path/to/my/custom-interpreter.

The custom interpreter would need to

1. inspect the script file it is being asked to run, and check whether it has the setuid bit enabled.
2. if not, then privileges should be dropped; otherwise, use seteuid to assume the privileges of the owner of the script.
3. use the execve system call (see man execve) to start the normal interpreter (e.g. /usr/bin/python3, for Python scripts) running, with the script supplied to it as an argument.

The custom interpreter would also need to be carefully coded to avoid the possibility of injection attacks and a wide range of other problems. Examples of custom interpreters which aim to do this can be found here and here. (Note: the safety of the code in these custom interpreters has not been vetted – use of it is at your own risk.)

Would a custom interpreter like this be a good idea? It’s doubtful. Programs like the Python interpreter are very large and complex, were not designed with running at elevated privileges in mind, and contain innumerable places in their code where security vulnerabilities could lurk.

Programs written in C have the disadvantage of not being memory-safe;⁸ but (if crafted carefully) they have the advantage that they can be kept extremely small and simple, with a very limited number of locations which need to be reviewed for security issues.

The issues raised by setuid scripts are discussed more in this StackExchange answer.