We provide security updates for the following versions:

• 3.0.x is the current release and receives all fixes, including security fixes.
• 2.x is not supported, including 2.7.x, the last 2.x release. Upgrade to 3.0.x; see Upgrading to 3.0.

If you discover a security vulnerability in bash-logger, please report it privately to help protect users.

1. Do NOT open a public issue for security vulnerabilities
2. Instead, use GitHub's private vulnerability reporting:
   • Go to the Security tab
   • Click "Report a vulnerability"
   • Provide detailed information about the issue

Alternatively, you can email the maintainer directly (see GitHub profile for contact information).

• Description of the vulnerability
• Steps to reproduce the issue
• Potential impact and severity
• Any suggested fixes or mitigations (if applicable)
• Your preferred method of acknowledgment (if desired)

• Initial Response: Within 5 business days
• Status Update: Within 10 business days
• Fix Timeline: Depends on severity
  • Critical: 7-14 days
  • High: 14-30 days
  • Medium/Low: 30-90 days

bash-logger includes a special function for handling sensitive information:

log_sensitive "Password: $secret"  # Only to console, never logged to file/journal

Important: Regular log functions (log_info, log_debug, etc.) will write to files and journals. Never log passwords, API keys, or other secrets using standard log functions.

See Sensitive Data Documentation for details.

Log files may contain sensitive information. Since 3.0, a log file that init_logger creates is readable and writable only by its owner (mode 600), and so is any directory it creates for the file. An existing file or directory keeps its permissions. To let a group read the log, create the file before calling init_logger, or change its mode afterwards.

init_logger refuses a log file path that is a symbolic link, and each write checks again, so a link put in place of the file later is not written through. A link created in the short time between that check and the write is not caught. Keep log files in a directory that other users cannot write to.

Always set appropriate permissions:

# Set restrictive permissions on log files
chmod 600 /var/log/myapp.log
chown myuser:mygroup /var/log/myapp.log

# Or create with secure permissions
touch /var/log/myapp.log
chmod 600 /var/log/myapp.log

Consider using log rotation with proper permission handling (e.g., logrotate with create directive).

Configuration files may contain paths and settings that reveal system information:

# Protect configuration files
chmod 640 /etc/myapp/logging.conf
chown root:mygroup /etc/myapp/logging.conf

bash-logger does not execute user-provided strings as commands. However, if you log user input, be aware of:

• Log injection: User input containing newlines can create fake log entries
• Terminal escape sequences: Malicious sequences in logged data could affect terminal viewers

Mitigation:

# Sanitize user input before logging
user_input="${user_input//[$'\n\r']/}"  # Remove newlines
log_info "User provided: ${user_input}"

When using systemd journal integration:

• Journal entries are visible to users in the systemd-journal group
• Consider journal access permissions for sensitive applications
• Use --tag to help with filtering and access control
• Review journalctl access controls in your environment

When sourcing the logging module, verify its integrity:

# Verify checksum before sourcing (in production)
expected_checksum="..."
actual_checksum=$(sha256sum /path/to/logging.sh | cut -d' ' -f1)

if [[ "$actual_checksum" != "$expected_checksum" ]]; then
    echo "ERROR: logging.sh checksum mismatch!" >&2
    exit 1
fi

source /path/to/logging.sh

If you accept log file paths from user input or configuration:

# Validate log file path
log_file="$1"
if [[ "$log_file" == *".."* ]] || [[ "$log_file" != /* ]]; then
    echo "ERROR: Invalid log file path" >&2
    exit 1
fi

init_logger --log "$log_file"

bash-logger includes several hardening measures to protect against common shell script security issues:

The logger command used for journal integration is validated at initialization:

• Full path to logger is determined using command -v
• Path is validated to be in trusted system locations:
  • /bin/logger
  • /usr/bin/logger
  • /usr/local/bin/logger
  • /sbin/logger
  • /usr/sbin/logger
• Logger executables in unexpected locations are rejected
• This prevents PATH manipulation attacks where a malicious logger executable could intercept journal logs

If journal logging fails validation, an informative warning is displayed, and journal logging is disabled for safety.

Internal constants are protected from malicious environment variable override:

• Log level constants (LOG_LEVEL_*) are declared as readonly
• Color constants (COLOR_*) are declared as readonly
• Variables are unset (if not already readonly) before initialization
• This prevents attackers who control the environment from:
  • Changing log level numeric values to disrupt logging logic
  • Injecting malicious ANSI codes via color constants
  • Bypassing log level checks

Example attack prevented:

# Attacker attempts to override constants
export LOG_LEVEL_INFO=999
export COLOR_RED="MALICIOUS_ESCAPE_SEQUENCE"

# bash-logger will detect and reset these values
source logging.sh  # Values are forced to correct constants

bash-logger uses version guards to prevent issues when sourced multiple times:

• Constants are only initialized once
• Re-sourcing does not attempt to redeclare readonly variables
• This prevents errors in environments where the library may be sourced multiple times

The guards check whether a constant is readonly (not merely set), so a value inherited from the environment cannot skip initialisation. The check tries to unset the variable in a subshell, which fails only for a readonly variable. It parses no output: before 3.0 it read readonly -p, where dash and busybox ash print values with literal newlines, so a readonly variable whose value contained a newline and readonly NAME=... could make another variable look readonly.

The following common security concerns are not applicable:

• SQL Injection: bash-logger does not interact with databases
• XSS/CSRF: bash-logger is not a web application
• Remote Code Execution: bash-logger does not accept or execute remote code
• Authentication/Authorization: bash-logger does not implement access control (relies on OS permissions)

bash-logger has no external dependencies except:

• A supported shell: bash 3.2 or later, zsh, dash or busybox ash
• Standard Unix utilities (cat, grep, wc, date, etc.)
• Optional: logger command for journal integration (part of util-linux)

This minimal dependency surface reduces supply chain risk.

When using bash-logger in your applications:

1. Never log sensitive data with standard functions
2. Set restrictive permissions on log files. A file that init_logger creates is already mode 600. Use 640 and chgrp only to share it with a group
3. Validate user input before logging
4. Review journal access if using systemd integration
5. Rotate logs to prevent information accumulation
6. Sanitize log output when displaying to users
7. Use version control to track changes to logging.sh
8. Test in staging before deploying changes

We appreciate responsible disclosure of security issues. Contributors who report valid security vulnerabilities will be acknowledged (with permission) in:

• The security advisory
• The CHANGELOG for the fix release
• This SECURITY.md file (if desired)

• OWASP Logging Cheat Sheet
• Systemd Journal Security
• Bash Security Best Practices

Thank you for helping keep bash-logger and its users secure!