Benchmark fails: 10.5 Lock Inactive User Accounts

[cpliakas]

The changes for the 10.5 don't appear to be sticking. The CIS-CAT Benchmark Assessment Tool suggests using the useradd -D | grep INACTIVE command to check the default value, which always returns -1 despite the changes written to /etc/login.defs. The tool also suggests running the useradd -D -f 35 command to change the setting.

I am not 100% psyched about this PR, but it does result in a passing benchmark. Posting the issue to start the discussion.

[pchaigno]

Why is bash -c required here?

[cpliakas]

Good question. When I just did useradd -D | grep -oP '(?<=^INACTIVE=)-?[0-9]+', for some reason it said that -P was not a valid option for useradd. I tried various methods of escaping the pipe and other things, but this is the only thing that worked.

I got the technique from http://stackoverflow.com/a/24685924. Seems like the shell module could also be a workaround.

[pchaigno]

Okay. In that case I think using the shell module would be cleaner, since we end up using a shell anyway. @awailly What do you think?

[awailly]

Yes, the command module will execute the process, and using the shell you will wrap the string with bash as you did. So yes, using the shell module is better here to keep the code simple.

[pchaigno]

Thanks for the pull request!

The Travis build is failing because, when it does a second playbook run, it finds an incorrect INACTIVE value again. It's as if 10.5.2 wasn't applied. Does it work correctly on your end?

[cpliakas]

The assessment tool is reporting that it is working.

Digging in a little deeper, after running the role with the pull request applied, I get the following output when running the following commands as a normal user:

$ useradd -D | grep INACTIVE
INACTIVE=-1
$ sudo useradd -D | grep INACTIVE
INACTIVE=35

So, running useradd via sudo seems to pick up the value. Also, in the useradd man pages, the instructions for the -f option are below:

       -f, --inactive INACTIVE
           The number of days after a password expires until the account is permanently disabled. A value of 0 disables the account as soon as the password has expired, and a value of
           -1 disables the feature.

           If not specified, useradd will use the default inactivity period specified by the INACTIVE variable in /etc/default/useradd, or -1 by default.

Looking at the /etc/default/useradd file, I do see INACTIVE=35. This is the info I have, so whether the change I posted is valid or not, it looks like the /etc/login.defs file might not the right place to make this change regardless.

[awailly]

I haven't tested, but will the user be locked if he was not created using useradd, like adduser? I feel like this solution is dependent on useradd, while login.defs was systemwide.