fix(10-042): Limit user lookups to "local" NSS passwd databases

[s3lph]

By default, only users from files, compat, db and systemd backends are enumerated. If other backends are active, a warning is emitted. This behavior can be customized with the new limit_nss_backends module parameter and the linux_allowed_ssh_nss_backends Ansible variable. Closes #28.

Also emits a warning if AuthorizedKeysCommand is enabled.

[Melkor333]

Sadly this change doesn't work with the veryvery sadly-old centos7 systems apparently still using python2.7:

TASK [adfinis.maintenance.maintenance_10_linux : 10-042: Security: SSH keys: Check for unknown or outdated keys for root and all users] ******************************************************************************************************
fatal: [SYSTEM]: FAILED! => {
    "changed": false,                        
    "rc": 1
}                                                   
                                                           
MSG:                                             
                                                           
MODULE FAILURE                        
See stdout/stderr for the exact error    
                                                           

MODULE_STDOUT:


Traceback (most recent call last):
  File "/home/adfshie/.ansible/tmp/ansible-tmp-1675079764.4848535-92441-256898518998322/AnsiballZ_audit_ssh_authorizedkeys.py", line 107, in <module>
    _ansiballz_main()
  File "/home/adfshie/.ansible/tmp/ansible-tmp-1675079764.4848535-92441-256898518998322/AnsiballZ_audit_ssh_authorizedkeys.py", line 99, in _ansiballz_main
    invoke_module(zipped_mod, temp_path, ANSIBALLZ_PARAMS)
  File "/home/adfshie/.ansible/tmp/ansible-tmp-1675079764.4848535-92441-256898518998322/AnsiballZ_audit_ssh_authorizedkeys.py", line 48, in invoke_module
    run_name='__main__', alter_sys=True)
  File "/usr/lib64/python2.7/runpy.py", line 170, in run_module
    mod_name, loader, code, fname = _get_module_details(mod_name)
  File "/usr/lib64/python2.7/runpy.py", line 113, in _get_module_details
    code = loader.get_code(mod_name)
  File "/tmp/ansible_adfinis.maintenance.audit_ssh_authorizedkeys_payload_ZA2eHS/ansible_adfinis.maintenance.audit_ssh_authorizedkeys_payload.zip/ansible_collections/adfinis/maintenance/plugins/modules/audit_ssh_authorizedkeys.py", line 1
55
    db, *backends = line.split()
        ^
SyntaxError: invalid syntax



MODULE_STDERR:

Shared connection to 172.22.255.2 closed.

---

(BTW, note to myself: In this case the ansible-molecule from #27 tests could've already caught this.)

[s3lph]

@Melkor333 should be fixed now, please check again

[Melkor333]

Tested it and works now, thanks! One thing though:
When sss is not in the list of modules but configured it warns that sss is not controlled and manual interaction is required.
IMO that doesn't make sense. It should be OK when sss is excluded. The better solution is to include sss per default. The whole idea is that we want as least manual interaction as necessary.

There's also the warning "[WARNING]: AuthorizedKeysCommand is configured: "/usr/bin/sss_ssh_authorizedkeys". Keys returned by this command are not audited." Can this warning be "acknowledged" so that the check will return OK or is the idea that the check should just be completely disabled in case an AuthorizedKeysCommand is used?

[s3lph]

@Melkor333

IMO that doesn't make sense. It should be OK when sss is excluded.

Why should it report OK? The task knows there is a portion of users it is not scanning, who can potentially sign in. I don't think it's wise to let the automated task decide whether that's actually ok; that decision should be made by an admin.

The better solution is to include sss per default. The whole idea is that we want as least manual interaction as necessary.

Is it? Enumerating all sss users and scanning their authorized_keys leads to people starting to wonder why the playbook "hangs". Even in the issue report (#28), @adf-patrickha had to resort to strace'ing the ansible execution in order to figure out what was going on. Because of this I think it should be a conscious decision to scan all user homes.

There's also the warning "[WARNING]: AuthorizedKeysCommand is configured: "/usr/bin/sss_ssh_authorizedkeys". Keys returned by this command are not audited." Can this warning be "acknowledged" so that the check will return OK or is the idea that the check should just be completely disabled in case an AuthorizedKeysCommand is used?

Again, the idea is that the admin should decide what to do in this case. And in the case of this task (10-042), I think this decision should be reevaluated with every maintenance run, as the set of users that can access a system could very well have changed between runs.

[Melkor333]

Again, the idea is that the admin should decide what to do in this case.

Yeah in case of AuthorizedKeyCommand the only sane solution is to check manually.

Why should it report OK? The task knows there is a portion of users it is not scanning, who can potentially sign in.

If you need to manually disable sss, this is actually fine - because by disabling the sss backend you say "It's okay to ignore these users". I don't know which customers currently do have sss configured, but I can imagine that we actually don't have to track these users. But tracking the ssh_keys of e.g. the root user makes still a lot of sense in this cases.
But that assumes that sss is enabled by default and needs to be disabled, which probably doesn't make sense.
A quick fix could be to see if any authoriyed_keys file exist for a non-local user, but I don't know how hard this is to achieve.

It's just in reality that any task which has be evaluated every time during maintenance (and might overwhelm the admin) is bringing the users further towards "meh I'll just ignore the checks, I don't think anything bad happened here" which is currently a bit of a bad practice.

Could we maybe just change the message from Please audit manually or include the backend in limit_nss_backends to something like Please make sure there are no SSH Keys from external (e.g. ldap/AD) users which shouldn't be there, or include the backend in limit_nss_backends or something the like?

(Btw. the warning threw me off quite a bit since the actual variable to be set is linux_allowed_ssh_nss_backends. But I don't see how to make this immediately visible to the user)

[s3lph]

If you need to manually disable sss, this is actually fine - because by disabling the sss backend you say "It's okay to ignore these users"

This is not the intent of the limit_nss_backends param introduced in this PR. This is implemented because remote user backends with lots of users (e.g. sssd) may take a long time to be checked, as reported in #28.

But I think I now understand your motivation. I'd propose to augment limit_nss_backends with a second parameter ignore_nss_backends. This second param can then be used to control which backends are safe to be skipped. E.g.:

1. Default options: limit_nss_backends=[files, compat, db, systemd] ignore_nss_backends=[]
2. Playbook is run, emits warning about sss being skipped and reporting as changed.
3. Admin decides on how this should be treated and adjusts host_vars accordingly:
   1. Audit sss users: limit_nss_backends=[files, compat, db, systemd, sss] ignore_nss_backends=[]
   2. Acknowledge that sss users are skipped and decide it's safe to skip them: limit_nss_backends=[files, compat, db, systemd] ignore_nss_backends=[sss]
   3. No action, audit sss users manually, host_vars remain on default values.

What are you thoughts on this @Melkor333 @SaschaD-Adfinis?