What criteria could I take in order to to allow or disallow the execution of bash scripts with sudo as root?

I know I should analyze the script but I have not enough time and I trust my developers.

My criteria today is to request the script user owner, group owner and permissions just to be sure the owner and group are root and permissions don't allow the user to modify the script.

For example, is there any tool in order to extract the commands executed within a bash script? I think with this list of command I would be able to evaluate if all command requiere root privileges or not.

4 Answers 4


A few options:

  • Read through the script once, make it r-x, change ownership, and add the script to the sudoers entry for the developers
  • Require that the developers use sudo in the script, rather than on executing the script, and whitelist commands in the sudoers file
  • Trust your developers and accept the risk

As far as extracting commands, there's only one right way to do that: read the script. You could turn on auditing or read the command history or something, but if it's truly malicious, those can't be relied upon.


I had same issue with SQL script launched with power-user (not exactly root, but close). So I made a list of commands that would arm my database, and maintained this list over time.

You may maintain a list of forbidden commands - we can't say what you want to avoid, but it seems hard to me to forbid rm.. you may just raise a warning when you do your checking.

So the idea would be to have a grep command do that for you - here it uses a list of patterns in pattern_file, and -r in case you have sub-directories to search:

grep -f pattern_file.txt -r /sudo_shells_repo/* 

Have this run as a verification script each time someone come and add an "executable with sudo" script in the repository.

  • I think this can be easily evaded. Signature based analysis like this one will not work against languages like bash which allow dynamic generation and execution of code. Sep 7, 2016 at 17:10
  • @SteffenUllrich Of course. But here Eloy says he trust his developers.
    – J. Chomel
    Sep 7, 2016 at 19:18
  • So why checking at all if he trusts them? Why making sure that the owner cannot modify the script? Sep 7, 2016 at 19:19
  • 1
    Because they may do mistakes or disregard rules.
    – J. Chomel
    Sep 7, 2016 at 19:20
  • 1
    So trusting that the developer is not malicious but not trusting that the developer knows what he does? As long as the developer is the only one having sudo access to this script this should not be a problem since he is not malicious. Problem could be if the account got hacked and the script is used for elevation of privileges. In this case I would not recommend a black list of command but a white list, because a black list is never complete (new commands gets installed...). And to apply a white list in an automatic way one would need a good enough parser for bash, grep is not enough. Sep 7, 2016 at 19:46

is there any tool in order to extract the commands executed within a bash script

Yes - bash.

But slightly less facetiously, no. Even an instrumented version the command interpreter will only show you what the script has done after it has done it. And treating the script as a black box means you can never be sure about what it will do in future, even assuming you can accurately capture the before and after states of running the script.


 if [ ! -d "/home/disgruntled" ] ; then 
    unset stuff

 rm -rf "$stuff/"
  • Thanks. I agree. But what I'm looking for is what I can do to improve security in this scenario... Sep 7, 2016 at 17:05
  • You know the answer; ensure there is adequate code review and managed deployment
    – symcbean
    Sep 7, 2016 at 23:59

extract the commands executed within a bash script?

You are effectively trying to match the code against a set of known bad signatures, similar to what IDS and antivirus do in the simplest case. But this does not work because bash is a very capable language where you can dynamically create commands and execute these. This can not be found by a simple pattern matching.

For example the following will execute bash -i, i.e. an interactive shell which provides the attacker with a privileged shell when executed with sudo.

bar='h -i'

Even if you create a signature for this code it can be easily modified so that it does not match the signature any longer. Or that the signature matches also valid code, i.e. false positive. And if you are trying a more advanced dynamic analyses it is also possible to make this code depend on time or files or just read new commands directly from a file or socket etc.

Conclusion: No script should be authorized without manual analysis.

  • 1
    You have said what I cannot do but, what can I do? Your conclusion is that bash scripts should not be authorized to run as root with sudo? Sep 7, 2016 at 17:00
  • 1
    @EloyRoldánParedes: No script should be authorized without manual analysis. And better all but the most obvious simple bash scripts should not be authorized. Keep in mind also that some programs started from this script can allow escalation of privileges. Typical example is to allow vi /some/special/file where the user can execute arbitrary commands from inside vi with <ESC>:!cmd. Sep 7, 2016 at 17:08

You must log in to answer this question.

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