/etc/security Hardening? - Console Lockdown - pam_access - access.conf

Development
,
18

new description:

  • Console Lockdown.
    Allow members of group ‘console’ to use console and members of group ‘ssh’
    to receive incoming SSH connections. Everyone else except members of group
    ‘console-unrestricted’ are restricted from using console using ancient,
    unpopular login methods such as using /bin/login over networks, which might
    be exploitable. (CVE-2001-0797) Using pam_access.
    Not enabled by default in this package since this package does not know which
    users shall be added to group ‘console’ and/or ‘ssh’ and would break console,
    X Window System and ssh login since files in
    /usr/share/pam-configs/console-lockdown-security-misc result in modifications
    of /etc/pam.d/common-account file which not only applies to /etc/pam.d/login
    but also all other services such as /etc/pam.d/ssh.

This is done.

anon-base-files /debian/anon-base-files.postinst:

           user_to_be_created=user

           ## security-misc: Console Lockdown.
           ## Make sure this group exists. Might not exist if security-misc is not (yet) installed.
           addgroup --system console
           addgroup --system ssh

           ## security-misc: Console Lockdown.
           addgroup "$user_to_be_created" console
           addgroup "$user_to_be_created" ssh

           ## By package security-misc.
           pam-auth-update --enable console-lockdown-security-misc

           ## In Qubes and for existing installations Console Lockdown is
           ## is handled by whonix-legacy package.

But as you see it adds user user to both groups, console and ssh. This is non-perfect. Will elaborate under [1].

security-misc /debian/security-misc.preinst how has code to refuse installation if no user is a member of group console or console-unrestricted. Additinoally, if the ssh.service is activated (user has OpenSSH server package openssh-server instlled) it refuses installation if no user is a member of group ssh.

Therefore security-misc could enable console lockdown by default and probably will after some testing.

[1] I don’t think it’s possible to have a perfect solution for console lockdown. It needs basic information - are you going to use SSH or not? Breaking SSH servers of new or existing installations is not an option.

Instead, I’ve invented a new tool /usr/bin/hardening-enable which I describe here in more detail:

Maybe this configuration question SSH vs no-SSH could be asked during first boot.

1 Like