As explained here (https://www.helpnetsecurity.com/2014/06/27/exploiting-wildcards-on-linux/), the tar command can be used to execute arbitrary code.

Is there a list of Linux commands, preferably including commands in packages in the official distro repos, along with whether they are known to have any functionality which executes user-supplied code? Of course, such an analysis could not determine that a command is secure, just that there is not a well-published way to execute arbitrary code.

EDIT: The system has a quite a few commands whitelisted, and although there is a legitimate use for all of them (eg. kill to kill a hung VPN connection) I think there might also be some illegitimate uses. I am not asking whether to apply the principle of least privilege, but if I am applying it effectively here. Rather than just asking about the specific commands on my system, I decided to ask a more general question.

| improve this question | | | | |
  • 4
    Are you asking in general what common command line utilities have the ability to execute code that isn't particularly obvious? If so, the list is massive. Even less can execute code via the LESSOPEN variable (note that sudo strips most variables by default, but it could still be set in a config file). – forest Jun 28 '18 at 2:49
  • 6
    I believe it is better to whitelisting than blacklisting. So i believe it is best just to allow sudo only those commands you need. – Muhammad Jun 28 '18 at 3:59
  • 2
    There's a LOT of commands that can execute a shell: less, more, vim, make, man, emacs, just to name a few. Whitelist the few commands the user really needs. – ThoriumBR Jun 28 '18 at 13:15
  • @forest Exactly; that is a good example of what I am asking for. – Arcanum Jul 6 '18 at 20:50
  • @Arcanum If environmental variables count, then the answer is literally all, simply by setting LD_PRELOAD to point to a library that hooks, say, __libc_start_main. – forest Oct 31 '18 at 3:34

What is it you're trying to protect against? You sound like you're trying to protect against malicious users deliberately trying to gain further access to the system.

In that case, I'd suggest trying to find some other way for users to accomplish the same thing, without using sudo. Well written suid scripts that accomplish the same thing, for instance. sudo should be limited to users you trust, and users competent enough to understand Linux commands (more below).

You should also consider the case where the users are non-malicious, but have a deadly combination of incompetence, and over-confidence. Several years ago I gave sudo access on a development server to a developer who was non-linux savy. Within a week she completely destroyed the linux server environment with a find -exec command she found though googling how to fix her code. She didn't understand the implications of the find -exec command, and it completely changed all the permissions on the filesystem (including setting critical system binaries to non-executable). I rebuilt the server, talked to her about the power of the find command, and removed her sudo access.

In both cases, you could likely still use whitelisting to give you some level of protection. The problem with this approach is that raw linux commands run as root are extremely powerful, and it's difficult to anticipate all the ways either maliciousness or incompetence could bite you. Honestly, eliminating the need for sudo in the first place is still likely the best option.

| improve this answer | | | | |

@Muhammad's comment has the right of it. If you want to limit what your users/local software can do, and prevent arbitrary behavior, but you also want to give sudo access, your only option is to whitelist commands (either combinations of full program paths with parameters or an explicitly specified lack of parameters, or simply full program paths that have no way to get arbitrary file overwrite or code execution - which amount to the same thing - out of them regardless of parameters). The sudoers file supports this.

In addition, you need to make sure that those commands are only installed in locations that non-root users cannot write to. Furthermore, you need to prevent commands that enable arbitrary modification of file names or contents. If you allow sudo with /bin/ls (which might be safe; I'm making no promises here) but also allow some command that lets me put arbitrary text into a file, I can use the second command to replace /bin/ls with a shell script that does whatever I want, and then run sudo ls and take arbitrary actions as root (or whatever user /bin/ls was set to run as in sudoers).

Generally, sudo access needs to be restricted to fully-trusted users, or to very specific commands that need to execute with certain privileges but cannot be used as leverage to gain those privileges more broadly. Note that you can mix these (for example, letting all members of the "wheel" group use arbitrary commands, and whitelisting specific commands for other users).

EDIT. I previously said you had to make sure that you were filtering on full paths, but sudoers only allows full paths and sudo builtins, so that's kind of a red herring.

| improve this answer | | | | |
  • This isn't the correct way to do it, you should read the sudoers(5) manual page to see how to do this whitelisting correctly. In such a case, you can safely run sudo ls without specifying the absolute path. The configuration takes care of quite a lot. – forest Jun 28 '18 at 11:35
  • @forest I never said the user couldn't run sudo ls and have it work, the sudo /bin/ls wasn't meant to imply that the path was needed, just to make it clear you weren't invoking the shell built-in, which otherwise somebody might not realize. I've read sudoers(5), though, and I don't see what is incorrect here, unless you think by "commands" I mean "programs" rather than full command lines. Yes, sudoers can contain cryptographic digests of allowed programs, but that just leads to a race condition (TOCTOU), and I've never seen it used in practice. – CBHacking Jun 28 '18 at 12:27
  • That would only result in a TOCTOU bug if it were very badly implemented. And using paths does not make it clear that you are not invoking something like an alias or function (there is no ls builtin). You can easily create a function called /bin/ls that has priority over the actual program. In the sudoers, you would allow /bin/ls which would then permit anything that calls that, from doing cd /bin && sudo ./ls to sudo ls to sudo /bin/ls to even sudo /bin/../bin/ls, etc. – forest Jun 28 '18 at 12:33
  • @forest Per the manpage (did you read it?): Warning, if the user has write access to the command itself (directly or via a sudo command), it may be possible for the user to replace the command after the digest check has been performed but before the command is executed. A similar race condition exists on systems that lack the fexecve(2) system call when the directory in which the command is located is writable by the user. This is Ubuntu; sudo --version gives Sudo version 1.8.16 Sudoers policy plugin version 1.8.16 Sudoers file grammar version 45 Sudoers I/O plugin version 1.8.16 – CBHacking Jun 28 '18 at 12:39
  • Ah, so it is badly implemented. Well I'm not advocating for using digest checks anyway. – forest Jun 28 '18 at 12:41

Not the answer you're looking for? Browse other questions tagged or ask your own question.