exercise on ACL from computer security course

Question

You found this file lying on a system:

[user@localhost]$ ls -la executable -rwsr-xr-x 1 foo group 41836 2012-10-14 19:19 dangerous.exe

Do you notice anything wrong?

Answer 1

I've written an answer, but this seems like a "homework" question. I don't consider that bad, but I do suggest providing details about what you have figured out so far when asking such questions. This can both get you most useful answers, and assist you in combining pedagogical benefits intended by the instructor with those afforded by Internet communities--for example, by informing us about what you have and have not yet learned, or by making it so you can still figure out some of the solution yourself.

ACL stands for Access Control List. The problem here seems to relate to ordinary Unix-style permissions (see also FilePermissions), and not to ACLs. Specifically, this is an exercise about setuid executables, and about the executable permission bits for the group and other classes. (If this is an exercise you're currently working on, that might be enough of a clue for you to solve it.)

Why do I think this is not (also) about ACLs? There's no information about ACLs set on the file, in the output of ls -l. Even if there is an ACL-related problem with dangerous.exe, there's no information given that would point to or otherwise suggest it.

Furthermore, at least in Ubuntu, ls checks if a file's permissions are customized through an ACL, and if so, appends + to the end of the symbolic permissions string.

ek@Ilex:~$ ls -l foobar                  # no + in the output of ls
-rw-rw-r-- 1 ek ek 0 Sep 14 13:16 foobar
ek@Ilex:~$ setfacl -m g:adm:r foobar
ek@Ilex:~$ ls -l foobar                  # now there's a + in the output
-rw-rw-r--+ 1 ek ek 0 Sep 14 13:16 foobar

(Note, though, that there may be some Unix-like systems with different ACL implementations and/or where the default ls executable does not check for the presence of ACL rules on files.)

For more information on ACLs in Ubuntu, see FilePermissionsACLs. As for the other issues, detailed analysis follows.

---

First, some commentary about what is contrived about the problem, to help us keep in mind the sorts of things that are ordinary in exercises but shouldn't be ignored if encountered "in the field."

In real life, though this is unlikely what the exercise was focused on:

• A user called foo on a production system is odd.
  (Though perhaps it belongs to Fordham Oo, Jr.)

  And, more extremely, a user called user (as indicated in $PS1) is basically never a good idea.

  These names will likely be interpreted metasyntactically in communication between colleagues, and may even be accidentally seen that way late at night by a system administrator who's struggling with a mostly unrelated problem.

• Similarly, a group called group is basically never a good idea.

• A file called dangerous.exe whose history I don't know about is alarming. It's either improperly named or maybe it shouldn't be lying around.

Now for what will, in this situation, usually be main security-related concern.

In both real life and probably in the mind of whoever wrote the question:

• The s in -rwsr-xr-x means dangerous.exe is a setuid executable. This can be done with chmod:

  ek@Ilex:~$ ls -l dangerous.exe 
  -rwxr-xr-x 1 ek ek 0 Sep 14 12:29 dangerous.exe
  ek@Ilex:~$ chmod u+s dangerous.exe
  ek@Ilex:~$ ls -l dangerous.exe
  -rwsr-xr-x 1 ek ek 0 Sep 14 12:29 dangerous.exe

  Since dangerous.exe is setuid, it runs as its owner no matter who executes it. Occasionally this is appropriate, but unless used sparingly and carefully it can cause very serious security problems, facilitating undesired access to the account who owns the executable.

• But that's not all. We know this is especially likely to be a case where a security problem could arise. (If there are any users or services running on the system that ought to be prevented from doing things foo is able to do, that is. Which is likely. Remember that a system with just one human user will by default have other user accounts are used by the system to perform actions with reduced privileges.)

  This is due to the other permissions set on dangerous.exe. Because of the way its executable bits are set, anyone can execute dangerous.exe!

  -rwsr-xr-x 1 foo group 41836 2012-10-14 19:19 dangerous.exe
        |   \
        \    This x indicates all users other than foo and members of
         \   'group' may execute the file! That's almost definitely bad!
          \
            This x indicates anyone in the 'group' group may execute the
            file. Depending on what the 'group' group means and who's in
            it, that might be bad.

  How do we know this by inspecting -rwsr-xr-x 1 foo group 41836 2012-10-14 19:19 dangerous.exe? After the first character (which is - for normal files, d for directories, and l for symbolic links) come nine characters.

  The first three say if the user who owns the file can read, write, and execute it. (A - appears when the answer is no.) The next group of three say if members of the file's group owner, other than the user owner, can read, write, and execute it. And the final group of three say if if other users, who neither own the file nor are in its group owner, can read, write, and execute it.

  Therefore all users on the system can run dangerous.exe--and when they do, they are running it as foo rather than as themselves!

• For a file to be safely setuid (or setgid), it must be carefully written to ensure it can only be used to engage in appropriate actions. For example, the /usr/bin/passwd executable that runs when a user changes their password with the passwd command is setuid, and owned by root, so even when a limited user runs it, it runs as root. This is necessary, for it to make changes to the password database. But it's carefully written so that it will only make authorized changes.

  Depending on what privileges foo has on the system, this is likely a less severe problem than if a root-owned setuid executable had a bug that allowed it to be used in unintended ways. But it still is cause for alarm.

  If you were a system administrator in this situation, you may wish to consult with the user foo to see if the permissions they've set on dangerous.exe were a mistake. (Depending on the context and other elements of the situation, you might potentially take more immediate action.)