DISA STIG (Security Technical Implementation Guides) Audit Tool for Debian

[Patrick]

@madaidan

Went through all the “fails”.

Me too as per Dev/STIG - Whonix

@madaidan

Seems like verified boot?

Dev/STIG - Whonix

bash scripts/check-package-verify.sh >/dev/null 2>&1 & spinner $! output “SV-86479r2_rule” $?

Probably porting issue. check-package-verify.sh [archive] does not test anything security relevant.

@madaidan

pam_cracklib has been discussed before.

Yes, comments added there and linked to open discussions.

[1] Defended in other ways. See [[Dev/Permissions]]. Unclear rationale. Discussed here: enforce minimum password strength / pam-cracklib - #4 by Patrick

@madaidan

[ FAIL ] The operating system must disable account identifiers (individuals, groups, roles, and devices) if the password expires.

We don’t set password expiry limits and they’re more likely to just annoy users.

Agreed. Added comment:

Same as [1].

Expiry limits would likely just annoy users. This might be more useful in an enterprise context where shoulder surfing might be an issue.

TODO: document shoulder surfing

@madaidan

[ FAIL ] Accounts subject to three unsuccessful logon attempts within 15 minutes must be locked for the maximum configurable period.
[ FAIL ] If three unsuccessful root logon attempts within 15 minutes occur the associated account must be locked.

We do lock accounts although after 50 failed logins rather than 3.

Right. Added comment:

Same as [1].

Set to 50 before unlockk procedure is required. 50 attempts is far to less for bruteforce.

Setting it to 3 might fall victim to some bugs. There are cases involving sudo where 1 login attempt is recognized as 3 due to pasting text by mistake into the terminal emulator. We might incrementally lower 50 over the releases if that seems worthwhile but not to 3. Can be discussed in protect Linux user accounts against brute force attacks

@madaidan

[ FAIL ] The delay between logon prompts following a failed console logon attempt must be at least four seconds.

pam_faildelay has been discussed before.

Same as [1].

@madaidan

[ FAIL ] The operating system must prevent the installation of software, patches, service packs, device drivers, or operating system components of local packages without verification they have been digitally signed using a certificate that is issued by a Certificate Authority (CA) that is recognized and approved by the organization.

Apt does signature verification.

Likely a false positive but should check the code of the test just to make sure.

@madaidan

[ FAIL ] The operating system must define default permissions for all authenticated users in such a way that the user can only read and modify their own files.

permission-lockdown does this.

Likely also a false positive but need to check the test code. Similar for other false positives.

@madaidan

[ FAIL ] File systems that contain user home directories must be mounted to prevent files with the setuid and setgid bit set from being executed.

remount-secure does this.

needs development, tracked in (re-)mount home [and other?] with noexec (and nosuid [among other useful mount options]) for better security?

Mostly agreed with your other comments

@madaidan

TLDR: Nothing useful and this is why I really dislike these types of hardening guides.

Dev/STIG - Whonix

Initial impression:

• Mostly applicable to governmental or enterprise environments.
• Whonix / Kicksecure is not an enterprise operating system yet. Such a flavor might be possible in future if an enterprise pays for implementation of these features / such a flavor.
• Lots of false positives.
• Doesn’t test for and/or find anything catastrophic such as remote exploitable vulnerabilities.
• Would still be useful to work through the list and add comments for any reported failure.