Ransomware attacks could use zero-day exploits, but often an attacker will just fool a gullible user into running an executable by downloading and clicking.

Suppose we have a naive user and want to restrict them to the normal path. Is there any way to restrict them from creating a file with executable privilege?

Or, more generally, is there any way to build an access control list and define that this user may only execute files in this list?

  • 7
    To disable execution in this manner would prohibit users from being able to do anything on system. There is no mechanism for this in-built to the system or even with third party software that I am aware of to do this type of security lockdown
    – Thomas Ward
    Aug 12, 2019 at 13:18
  • 3
    not answering but hint what you can do: add noexec on user writable mounts. wont prevent scripts but actual binary execution. Aug 13, 2019 at 3:00
  • 3
    @ThomasWard, isn't that exactly what a restricted shell is ? Aug 13, 2019 at 8:39
  • 7
    @ThomasWard there is a general concept of 'whitelisted executables' where a certain list of (usually signed) executables is allowed and nothing else can be run without elevated privileges; and both Windows and OS X have reasonable solutions that do this. I don't know if there's a good Ubuntu (or other Linux) solution for application whitelisting, though.
    – Peteris
    Aug 13, 2019 at 10:28
  • 2
    @Peteris, there are multiple such solutions. My favorite is having a signed, read-only filesystem with your executables and mounting all others noexec, along the lines of how ChromeOS uses dm_verity to ensure root filesystem integrity. For folks who aren't quite that hardcore, one can use EVM modules; see wiki.gentoo.org/wiki/Extended_Verification_Module for Gentoo's documentation on same. Aug 13, 2019 at 21:31

2 Answers 2


The specific attack you've expressed concern about is:

often an attacker will just fool a gullible user into running an executable by downloading and clicking.

At least in the common case where the file is downloaded in a web browser, this should already be prevented in Ubuntu by the browser's adherence to the Execute-Permission Bit Required policy. The most directly relevant parts of that policy are:

  • Applications, including desktops and shells, must not run executable code from files when they are both:

    • lacking the executable bit
    • located in a user's home directory or temporary directory.
  • Files downloaded from a web browser, mail client, etc. must never be saved as executable.

So if a user is told to download a program in a web browser, does so, and attempts to run the file by double-clicking on it, it won't run. This applies even if the file downloaded is a shell script or even a .desktop file. (If you've ever wondered why .desktop files in your home directory have to be marked executable even though they're not really programs, that's why.)

It is possible for users to alter this behavior through configuration changes. Most will not, and while those who do probably shouldn't, that's not really what you have to worry about. The bigger concern is the more complex attack that I think you're already worried about, in which a malicious person (or bot) instructs the user to download a specific file, mark it executable themselves (through their file browser or with chmod), and then run it.

Unfortunately, restricting a user's ability to set the execute bit on a file or to execute files other than those on some whitelist wouldn't noticeably mitigate the problem. Some attacks will already work, and those that don't could be trivially modified so that they do. The fundamental issue is that the effect of running a file can be achieved even if the file doesn't have executable permissions.

This is best illustrated by example. Suppose evil is a file in the current directory that, if given executable permissions (chmod +x evil) and run (./evil), would do something evil. Depending on what kind of program it is, the same effect may be achieved by one of the following:

None of those, not even the last one, require that the file have executable permissions or even that the user be able to give the file executable permissions.

But the malicious instructions don't even have to be that complicated. Consider this non-malicious command, which is one of the officially recommended ways to install or update NVM:

wget -qO- https://raw.githubusercontent.com/nvm-sh/nvm/v0.34.0/install.sh | bash

The reason that's not malicious is that NVM isn't malware, but if the URL were instead to someone's script that does evil when run, that command would download and run the script. At no point would any file need to be given executable permissions. Downloading and running the code contained in a malicious file with a single command like this is, I believe, a pretty common action that attackers trick users into taking.

You might think of trying to restrict what interpreters are available for the users to run. But there isn't really a way to do this that doesn't substantially impact the ordinary tasks you presumably want users to be able to do. If you're setting up an extremely restricted environment on which nearly everything a user would think of to do on a computer is disallowed, like a kiosk that only runs a couple programs, then this might provide some measure of meaningful protection. But it doesn't sound like that's your use case.

So the approximate answer to your question is, "No." The fuller answer is that you could probably manage to prevent users from executing any files except those that you supply on a whitelist. But that's in the strict, technical sense of "execute," which is not needed to achieve the full effect of running most programs or scripts. To prevent that, you could try to make the whitelist very small, so it didn't list any interpreters except those that could be highly restricted. But even if you managed that, users couldn't do much, and if you made it so small they couldn't hurt themselves, they probably couldn't do anything. (See Thomas Ward's comment.)

If your users can hurt themselves, they can be fooled into hurting themselves.

You may be able to restrict specific programs from being used or otherwise behaving in ways that are likely to be harmful, and if you're looking at specific patterns ransomware tends to follow, you may be able to prevent some specific common cases. (See AppArmor.) That might provide some value. But it won't give you anything close to the comprehensive solution you're hoping for.

Whatever technical measures (if any) you end up taking, your best bet is to educate users. This includes telling them not to run commands they don't understand and not to use downloaded files in situations where they wouldn't be able to explain why it's reasonably safe to do so. But it also includes things like making backups, so that if something does go wrong (due to malware or otherwise), the harm done will be as little as possible.

  • 6
    Perhaps the non-technical measures need to include having contact info for someone that can sanity check something they want to do. Any time they're not sure, call or message and ask. That might remove the temptation to guess. Aug 13, 2019 at 2:32
  • 1
    This is a great abstract about the issues and fears behind OPs question Aug 13, 2019 at 8:38
  • Minor nit: ". ./evil or source ./evil runs the commands in evil.sh" - Those source commands would run the commands in evil unless they specify the extension, for example . ./evil.sh Aug 13, 2019 at 16:17
  • @DennisWilliamson Thanks--fixed! That was left over from an older (not submitted) rough draft of the answer in which I used different script names. I quickly realized that was silly, but apparently failed to change all occurrences. Aug 13, 2019 at 16:20
  • 2
    Every time I see a way to install or update a piece of software that involves "just wget this script and run it", my toenails curl a little. Nothing is stopping someone from creating a GitHub account/repo that's off by a single character, or uses 0 instead of O, or uses UTF-8 characters for obscurity and sticking their own malicious script in it... then all you need is one typo in your wget command and bam.
    – Ian Kemp
    Aug 14, 2019 at 6:28


It's called a restricted shell.

You can use /bin/rbash, which is already available in Ubuntu and combine that with a restricted PATH variable. The rbash will prohibit execution from anything that is not in $PATH.

Add a restricted user:

sudo adduser --shell /bin/rbash res-user

Make a new directory, where we can link binaries in, that the user will be limited to:

sudo mkdir /home/res-user/bin

Modify the .profile file:

sudo vim /home/res-user/.profile

if [ -n "$BASH_VERSION" ]; then
    # include .bashrc if it exists
    if [ -f "$HOME/.bashrc" ]; then
        . "$HOME/.bashrc"

readonly PATH=/home/res-user/bin
export PATH

Make the .profile, bashrc and .bash_profile immutable:

sudo chattr +i /home/res-user/.profile
sudo chattr +i /home/res-user/.bashrc
sudo chattr +i /home/res-user/.bash_profile

Now we give the user the only thing he will be allowed to do, i.e. open Firefox:

sudo ln -s /usr/lib/firefox/firefox /home/res-user/bin/

Now, if we login as res-user we can only open Firefox:

res-user@localhost:~$ /home/res-user/bin/firefox --version
Mozilla Firefox 68.0.1

We cannot easily escape our restricted shell:

res-user@localhost:~$ export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
-su: PATH: readonly variable

The restricted user cannot make files executable, or start them:

res-user@localhost:~$ chmod +x script.sh 
Command 'chmod' is available in '/bin/chmod'
res-user@localhost:~$ bash script.sh 
Command 'bash' is available in '/bin/bash'
The command could not be located because '/bin' is not included in the PATH environment variable.
bash: command not found

The restricted user cannot execute evil scripts from the internet, because the user cannot execute the necessary commands:

res-user@localhost:~$ wget -qO- https://raw.githubusercontent.com/nvm-sh/nvm/v0.34.0/install.sh | bash
Command 'wget' is available in '/usr/bin/wget'
The command could not be located because '/usr/bin' is not included in the PATH environment variable.
wget: command not found
Command 'bash' is available in '/bin/bash'
The command could not be located because '/bin' is not included in the PATH environment variable.
bash: command not found

* There are ways to break out of restricted shells, but if your user is capable of that, then they might not be as gullible as you think.

  • 2
    This tries to achieve "an extremely restricted environment on which nearly everything a user would think of to do on a computer is disallowed" (as I put it in my answer). res-user can't log in graphically. The only useful thing they can do is ssh -X in and run firefox. You can allow more commands so the user can do their work. Then breaking out gets easier. Several of the linked methods can be made into one-liners (which an attacker may supply). If users find restrictions stifling, they'll become experts at circumventing them, while remaining as savvy or gullible as they were before. Aug 13, 2019 at 12:13
  • 1
    @EliahKagan yes, correct. You'd have to link everything that the user needs. But this is very close to [...]is there any way to build an access control list and define that this user may only execute files in this list[...]. So it might help OP. Breaking out of these shells is not impossible, but pretty difficult. We've had similar setups for external access to specific resources, or jump-hosts. I doubt there are broad attacks out there, against restricted-shell setups.... and if you are dealing with a targeted attack, where the attacker knows the environment.. all bets are off anyway. Aug 13, 2019 at 12:22
  • 4
    I would elevate the footnote to the first line of your answer. Aug 13, 2019 at 16:24
  • 1
    Probably better to have them use chrome in kiosk mode or another hardened browser. It should be pretty easy to get a firefox plugin or extension installed with very elevated permission and system command execution. In firefox make sure you use the very last version and disallow extensions. Aug 13, 2019 at 19:31
  • For further protection give the user only write access to file systems mounted with the noexec option.
    – Dan D.
    Aug 14, 2019 at 3:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .