CITS3007 lab 3 (week 5) – 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 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 where 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.)

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.