Security and Hardening Basics with Bash Scripts Quiz

This quiz covers essential concepts of securing and hardening systems using Bash scripts, focusing on permissions, safe scripting practices, and common vulnerabilities. Ideal for beginners interested in bolstering system security through Bash automation and script management.

1. File Permissions in Bash Scripts

   Which Bash command can you use to make a script executable by the owner only, if the script file is named 'secure.sh'?

   1. chmod 700 secure.sh
   2. chmod 777 secure.sh
   3. chperm 755 secure.sh
   4. chown 777 secure.sh

   Explanation: chmod 700 secure.sh sets permissions so only the owner can read, write, and execute the script, which is a secure practice. chmod 777 makes it executable by everyone, which is unsafe for security reasons. chown changes ownership, not permissions, and chperm is not a valid Bash command. Using chmod 700 helps restrict access to sensitive scripts.

2. Script Injection Prevention

   When accepting user input in a Bash script, which best practice helps prevent command injection vulnerabilities?

   1. Using echo instead of read
   2. Running all inputs as root
   3. Ignoring user input
   4. Quoting variables in commands

   Explanation: Quoting variables ensures that user input is treated as literal text, reducing the risk of command injection attacks. Running scripts as root increases the potential impact of vulnerabilities. Using echo does not accept input, and ignoring user input defeats the script's purpose. Therefore, always quote variables when handling input.

3. Environment Variables Security

   In securing Bash scripts, why is it risky to rely on the PATH environment variable to locate executables?

   1. Attackers can alter PATH to run malicious executables
   2. PATH always points to system files only
   3. PATH makes scripts run faster
   4. Changing PATH is impossible in Bash

   Explanation: Attackers can manipulate PATH to execute harmful programs with the same name as trusted utilities, resulting in script compromise. PATH does not inherently make scripts faster, nor does it ensure executables are only from safe system directories. The claim that PATH cannot be changed is incorrect, as users can modify it.

4. Securing Temporary Files

   Why should you avoid using predictable temporary file names like '/tmp/tempfile' in security-sensitive Bash scripts?

   1. Attackers could pre-create or symlink the file to exploit the script
   2. Predictable names reduce code readability
   3. It speeds up execution
   4. It makes the script portable

   Explanation: If temporary file names are predictable, attackers may create files or symlinks in advance to trick scripts or gain access to sensitive data. Portability and readability are not significant security concerns in this context, and execution speed is unaffected by file name predictability. Using unique or randomized names mitigates this risk.

5. Safe Use of 'sudo' in Scripts

   What is a recommended practice when using 'sudo' in Bash scripts for hardening?

   1. Limit 'sudo' commands and specify the full path to commands
   2. Use 'sudo' at the start of every script
   3. Allow scripts to run unknown commands with 'sudo'
   4. Give all users passwordless 'sudo'

   Explanation: Limiting 'sudo' usage and specifying full paths reduces risks of privilege escalation or executing unintended binaries. Running every script as 'sudo' is unsafe and unnecessary. Passwordless 'sudo' is a security risk. Allowing scripts to run unknown commands undermines system integrity, so careful management of 'sudo' is crucial.

6. Reducing Script Permissions

   Which file permission setting helps minimize risk if a Bash script is accidentally modified by another user?

   1. Write permission for everyone
   2. Read, write, and execute for all
   3. Execute permission for nobody
   4. Read and execute only, without write permission for group or others

   Explanation: Allowing only the owner to read and execute, while denying write for group and others, prevents unauthorized modifications. Granting write to everyone exposes the script to tampering. Removing execute permissions entirely blocks script use. Full permissions to all users present substantial security risks.

7. Disabling Dangerous Bash Features

   To enhance security, which Bash feature should be disabled when running untrusted scripts?

   1. Case statements
   2. Command echoing
   3. Variable assignments
   4. Shell function exporting

   Explanation: Shell function exporting allows functions to be passed to subshells, raising the risk of attacks if mishandled. Command echoing and case statements are standard programming constructs and not direct security risks. Variable assignments themselves are not considered dangerous unless misused with untrusted data.

8. Validating User Input Types

   If a Bash script requests a user to enter a number, which practice best strengthens input validation?

   1. Accept any input without validation
   2. Convert the input to uppercase
   3. Automatically add quotes around input
   4. Use a regular expression to check the input format

   Explanation: Using regular expressions ensures that only valid numeric inputs are accepted, reducing the risk of injection or unintended behavior. Accepting input without checks allows invalid or malicious data. Simply quoting or converting to uppercase doesn't verify the expected type. Strong validation is a key security step.

9. Hardening with User Privileges

   Why is it important to avoid running Bash scripts as the root user unless necessary?

   1. Increases logging details
   2. Minimizes damage if the script is exploited
   3. Improves script speed
   4. Lets anyone use the script

   Explanation: Running scripts as a non-root user contains potential harm because exploits have limited privileges. Root-level scripts are more dangerous if compromised. User privileges do not significantly affect script speed or logging detail. Allowing anyone to use the script regardless of privilege is not a recommended security practice.

10. Preventing Information Disclosure

    In Bash scripting for security, what is an effective way to prevent sensitive data from being printed in terminal output?

    1. Avoid handling sensitive data in scripts
    2. Print data using 'echo' for transparency
    3. Use loud colors to highlight output
    4. Redirect sensitive output to a secure file and limit terminal echo

    Explanation: Redirecting output to a file with restricted permissions helps prevent exposure to unauthorized viewers. Simply printing with echo can display sensitive data to unintended audiences. Avoiding sensitive data is often impractical, and colorization does not provide security. Managing output properly safeguards confidential information.