The no_direct_root_logins check needs to check /proc/cmdline as well

[trevor-vaughan]

While checking our implementation of no_direct_root_logins, we found that, while the OVAL check passed, the system was still allowing root access.

This turned out to be because the kickstart files were adding the console to the bootloader option.

The OVAL check should be modified to also check the console option of /proc/cmdline to ensure that the system isn't bypassing the /etc/securetty file.

[shawndwells]

On 4/17/17 10:36 AM, Trevor Vaughan wrote:

While checking our implementation of |no_direct_root_logins|, we found that, while the OVAL check passed, the system was still allowing root access.

This turned out to be because the kickstart files were adding the console to the |bootloader| option.

The OVAL check should be modified to also check the |console| option of |/proc/cmdline| to ensure that the system isn't bypassing the |/etc/securetty| file.

Hmm. I have a bad feeling we need this for the various audit and FIPS flags, too....

[trevor-vaughan]

@shawndwells I kind of assumed that it was already there actually!

But, yes, definitely.

Also, it would be nice if securetty could ignore the kernel options through some sort of setting. It's very difficult to handle consoles in VM environments without setting this.

I'm thinking that it should turn off if you have one other user, in /etc/passwd, that has a password and is able to login. Don't want to randomly lock people out of systems.

[marcusburghardt]

The no_direct_root_logins rule is still used in some profiles but it is no longer so relevant in modern systems. The most update benchmarks, such as CIS and STIG, are recommending different approaches to restrict root access, like enforcing SSH, restricting root login in ssh, enforcing sudo, locking the root user, etc. Therefore, I don't think it is worth to expand the existing rule. It is about /etc/securetty and is doing what is expected.