ENT-13766: Fixes / improvements / security hardning

[larsewi]

• Suppress cleanup() errors for missing files
• Export NO_CONFIGURE so it propagates to autogen.sh subprocesses
• Harden SSH on build hosts: disable root login and password auth
• Install epel-release on all RHEL/CentOS versions
• Install and configure fail2ban on all build hosts

[olehermanse]

@larsewi isn't this exactly the same?

[olehermanse]

echo 'echo "  In child script:       NO_CONFIGURE=${NO_CONFIGURE:-<unset>}"' > autogen.sh

run_and_print_on_failure() {
    echo "  Inside function:       NO_CONFIGURE=${NO_CONFIGURE:-<unset>}"
    bash -c 'echo "  In child process:      NO_CONFIGURE=${NO_CONFIGURE:-<unset>}"'
    bash $1
}

echo "=== Test 1: prefix assignment ==="
(
    NO_CONFIGURE=1 run_and_print_on_failure autogen.sh
)

echo ""
echo "=== Test 2: export ==="
(
    export NO_CONFIGURE=1
    run_and_print_on_failure autogen.sh
)

$ bash test.sh
=== Test 1: prefix assignment ===
  Inside function:       NO_CONFIGURE=1
  In child process:      NO_CONFIGURE=1
  In child script:       NO_CONFIGURE=1

=== Test 2: export ===
  Inside function:       NO_CONFIGURE=1
  In child process:      NO_CONFIGURE=1
  In child script:       NO_CONFIGURE=1

[larsewi]

This is true for bash, but not dash. So it fails on the Debian 9 bootstrap host.

When a shell function is executed, the variables which are explicitly placed in the environment of the command (by placing assignments to them before the function name) are made local to the function and are set to the values given. Linux Man Pages

The key phrase is "local to the function" — dash makes them local, not exported. That means child processes spawned within the function don't inherit them.

[olehermanse]

The key phrase is "local to the function" — dash makes them local, not exported. That means child processes spawned within the function don't inherit them.

I think that's ambiguous, exactly what "local to the function" means here. My interpretation, which seems to align with all the shells I tested on is that "local to the function" means it will be unset after the function, but it will be set for subprocesses spawned inside the function. This also makes it so functions work "the same" / similarily as commands which start binaries / spawn subprocesses.

I tested in dash with Debian 12, exactly the same result - maybe a bug in debian 9 version of dash?

[olehermanse]

Interesting - tested with Craig and it does make a difference on Debian 9, but looks like a bug IMO:

echo 'echo "  In child script:       NO_CONFIGURE=${NO_CONFIGURE:-<unset>}"' > autogen.sh

in_sub_function() {
    echo "  Inside subfunction:    NO_CONFIGURE=${NO_CONFIGURE:-<unset>}"
}

run_and_print_on_failure() {
    echo "  Inside function:       NO_CONFIGURE=${NO_CONFIGURE:-<unset>}"
    dash -c 'echo "  In child process:      NO_CONFIGURE=${NO_CONFIGURE:-<unset>}"'
    dash $1
    in_sub_function
}

echo "=== Test 1: prefix assignment ==="
(
    NO_CONFIGURE=1 run_and_print_on_failure autogen.sh
)

echo ""
echo "=== Test 2: export ==="
(
    export NO_CONFIGURE=1
    run_and_print_on_failure autogen.sh
)

$ dash test.sh
=== Test 1: prefix assignment ===
  Inside function:       NO_CONFIGURE=1
  In child process:      NO_CONFIGURE=<unset>
  In child script:       NO_CONFIGURE=<unset>
  Inside subfunction:    NO_CONFIGURE=1

=== Test 2: export ===
  Inside function:       NO_CONFIGURE=1
  In child process:      NO_CONFIGURE=1
  In child script:       NO_CONFIGURE=1
  Inside subfunction:    NO_CONFIGURE=1

[craigcomstock]

yes, I really think we need a refined sshd config module though... as still managing just sshd_config is not really sufficient. If some of these options are present in sshd_config.d they may come in first and "win". So we need to compare the RESULTING configuration aka ssh -G output which shows the resulting configuration.