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

[Patrick]

Is there something in /etc/security/ folder that we could harden?

[madaidan]

We can set process limits in limits.conf to prevent things like fork bombs but that may be too restrictive as it won’t allow a legitimate user to start too many processes.

Apart from that, I don’t know of anything else than can be hardened.

[Patrick]

With the upcoming user / admin split limits might make sense. Could we
say user “user” can use “95%” (or something as high as possible) of
resources but keep “5%” available on demand for user “admin” / root to
give them the ability to shut down locked up user “user” accounts?

[Patrick]

pam_access

Quote https://linux.die.net/man/8/pam_access

By default rules for access management are taken from config file /etc/security/access.conf if you don’t specify another file.

What service reads /etc/security/access.conf?

grep -r -i pam_access /etc/pam.d

(commented out by Debian default)

/etc/pam.d/login:# account required pam_access.so

---

pam_securetty

Which services read the /etc/securetty configuration file?

grep -r -i pam_securetty /etc/pam.d

/etc/pam.d/login:auth [success=ok new_authtok_reqd=ok ignore=ignore user_unknown=bad default=die] pam_securetty.so

Quote https://linux.die.net/man/8/pam_securetty (bold is mine)

[…] This module has no effect on non-root users and […]

---

In Restrict root access if I remember right it was discussed that /etc/securetty contains lots of very unpopular, obscure login options and it is better to restrict that for better security hardening. But /etc/securetty is for root only.

Can we use pam_access to restrict non-root users from using obscure login options too? https://linux.die.net/man/5/access.conf says it can be used tl block non-local login. But pam_access would only be used for /etc/pam.d/login anyhow? /etc/pam.d/ssh (“remote login?”) is separate. Therefore /etc/pam.d/login “remote login” could be ancient, unpopular, obscure login options.

There was a /bin/login remote overflow vulnerability in past:

• https://www.giac.org/paper/gcih/293/buffer-overflow-bin-login/103062
• Linux pam_lib_smb < 1.1.6 - '/bin/login' Remote Overflow - Linux remote Exploit

Need to make sure that we don’t break serial console.

[madaidan]

@Patrick

With the upcoming user / admin split limits might make sense. Could we say user “user” can use “95%” (or something as high as possible) of resources but keep “5%” available on demand for user “admin” / root to give them the ability to shut down locked up user “user” accounts?

It doesn’t accept percentages,

Cgroups may be a better option for that. Systemd uses cgroups and user sessions are run under a systemd slice by default AFAIK so we can just edit that systemd.resource-control

@Patrick

Can we use pam_access to restrict non-root users from using obscure login options too?

Yes. Quickly looking over it, it seems we can use

+:user:tty1 tty2 tty3 tty4 tty5 tty6
+:root:tty1 tty2 tty3 tty4 tty5 tty6
-:ALL:ALL

Which would allow the user and root users to login form tty[1-6] and deny all other login options for every user (not just user and root).

[Patrick]

It’s implemented.

• security-misc/usr/share/pam-configs/console-lockdown-security-misc at master · Kicksecure/security-misc · GitHub
• security-misc/etc/security/access-security-misc.conf at master · Kicksecure/security-misc · GitHub
• https://github.com/Whonix/security-misc/blob/master/usr/lib/security-misc/pam_tally2-info

Why use accessfile=/etc/security/access-security-misc.conf and not /etc/security/access.conf? To avoid need for config-package-dev displace.

Why invent /usr/share/pam-configs/console-lockdown? Because pam_access is not used by Debian default pam config. No setting in /etc/security/access.conf has any effect without adding it to /etc/pam.d.

But I cannot enable it by default. Why? See description:

Console Lockdown.
Allow members of group ‘console’ to use console. 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 would break ssh login since files
in /usr/share/pam-configs/console-lockdown 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.

One part is easily solvable:

Not enabled by default in this package since this package does not know which
users shall be added to group ‘console’

pam console-lockdown could be enabled in package anon-base-files for Whonix / Kicksecure.

But the following part is not easily solved.

would break ssh login since files
in /usr/share/pam-configs/console-lockdown 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.

The following line

account  required        pam_access.so accessfile=/etc/security/access-security-misc.conf debug

needs to end up in /etc/pam.d/login only. Not in file /etc/pam.d/common-account. There is no API to modify /etc/pam.d/login with a package.

I am wondering if line account required pam_access.so accessfile=/etc/security/access-security-misc.conf debug could declare “but only for /etc/pam.d/login” or if /etc/security/access-security-misc.conf could declare “don’t break SSH”.

Any idea?

Instead of blocking all except recent (non-ancient) consoles…

+:console:tty1 tty2 tty3 tty4 tty5 tty6 tty7 pts/0 pts/1 pts/2 pts/3 pts/4 pts/5 pts/6 pts/7 pts/8 pts/9 hvc0 hvc1 hvc2 hvc3 hvc4 hvc5 hvc6 hvc7 hvc8 hvc9

could change that to

+:console:ALL

which would not block ancient consoles, would not break SSH but at least prevent users not in group console from attempting any login.

[madaidan]

Why not create an ssh group and allow those users to login via ssh?

[Patrick]

Would require adding.

+:ssh:ALL

Users of Linux distributions where console-lockdown gets enabled by default (Whonix, Kicksecure) trying to set up an incoming SSH connection could have a hard time. They’d need to add sudo addgroup user ssh.

Therefore should user user (and later user admin) be a member of group ssh by default? Imagine someone in not too far future installing Kicksecure on a VPS (using ISO installer using VPS web interface). Can’t ssh, because no default user is a member of group ssh.

Those not intending to use incoming ssh should remove themselves from group ssh. It’s not as hardened by default but otherwise huge usability mess. What do you think?

[madaidan]

@Patrick

Would require adding.

+:ssh:ALL

That looks too permissive. access.conf allows you to specify logins from IP addresses. Maybe there’s a way to allow the user to login over the network rather than allowing them to login from everything.

@Patrick

Users of Linux distributions where console-lockdown gets enabled by default (Whonix, Kicksecure) trying to set up an incoming SSH connection could have a hard time. They’d need to add sudo addgroup user ssh .

Therefore should user user (and later user admin ) be a member of group ssh by default? Imagine someone in not too far future installing Kicksecure on a VPS (using ISO installer using VPS web interface). Can’t ssh, because no default user is a member of group ssh .

Those not intending to use incoming ssh should remove themselves from group ssh . It’s not as hardened by default but otherwise huge usability mess. What do you think?

I don’t think they should be part of the ssh group by default as the majority of Whonix users probably won’t be using SSH but it should be documented in the wiki.

[HulaHoop]

@Patrick

What if you add “user” to ssh while also hardening/tightening the rights of the ssh group? This way you don’t break expected behavior for sysadmins while also improving security. Perhaps prevent any non Torrified connection for the ssh group for Kicksecure too.

Perhaps one day automate creation of HS3 services with ssh initiation?

[Patrick_mobile]

@HulaHoop

What if you add “user” to ssh while also hardening/tightening the rights of the ssh group?

@madaidan

That looks too permissive. access.conf allows you to specify logins from IP addresses. Maybe there’s a way to allow the user to login over the network rather than allowing them to login from everything.

I didn’t figure out how that would be possible.

[HulaHoop]

@madaidan

That looks too permissive. access.conf allows you to specify logins from IP addresses. Maybe there’s a way to allow the user to login over the network rather than allowing them to login from everything.

Network namespaces?

[madaidan]

@HulaHoop

Network namespaces?

I don’t see how they could be used for this.

[HulaHoop]

How to restrict an SSH user to only allow SSH-tunneling?

---

Whitelisting the sshd allowed addresses can work by adding a special internal IP that uses Tor’s mapadddress to refer to some onion address generated for SSH access later on.

How to restrict or allow ssh only from certain users, groups or hosts in Linux...

[madaidan]

We can use

+:ssh:ALL EXCEPT LOCAL

Which should allow the ssh group to login anywhere except local things which should only be the network.

[Patrick]

@HulaHoop

unix.stackexchange.com

How to restrict an SSH user to only allow SSH-tunneling?

linux, ssh, account-restrictions

asked by LanceBaynes on 08:47AM - 03 Jun 11 UTC

Whitelisting the sshd allowed addresses can work by adding a special internal IP that uses Tor’s mapadddress to refer to some onion address generated for SSH access later on.

GoLinuxCloud – 3 May 19

How to restrict or allow ssh only from certain users, groups or hosts in Linux

How to allow SSH for root login only from specific host or IP address? How to configure and restrict SSH to permit login only for certain users and/or groups?

That might be further SSH related hardening. Please open a new forum thread or phabricator ticket for this. The purpose of this thread is to find optional hardening and we’re bound to the features / syntax of these files:

• https://linux.die.net/man/8/pam_access
• https://linux.die.net/man/5/access.conf

Which is limited.

@madaidan

We can use

+:ssh:ALL EXCEPT LOCAL

Which should allow the ssh group to login anywhere except local things which should only be the network.

Did that.

separate group "ssh" for incoming ssh console permission

description

[Patrick]

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.

@Patrick

One part is easily solvable:

Not enabled by default in this package since this package does not know which
users shall be added to group ‘console’

pam console-lockdown could be enabled in package anon-base-files for Whonix / Kicksecure.

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].

@Patrick

But the following part is not easily solved.

would break ssh login since files
in /usr/share/pam-configs/console-lockdown 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.

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:

Security Hardening Tool - /usr/bin/hardening-enable by security-misc

/usr/bin/hardening-enable It can be used to easily opt-in everything advanced. For now it has these features: /usr/bin/hardening-enable --ssh [Hide Hardware Info] Enabling enable hide-hardware-info.service by running ‘systemctl enable hide-hardware-info.service’… Success. [NOEXEC] Enabling noexec by creating file /etc/noexec … Success. [LKRG - Linux Kernel Runtime Guard] LKRG hardening by creating /etc/sysctl.d/40-security-misc-autogenerated.conf … Success. Or. /usr/bin/hardenin…

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

[Patrick]

Dec 10 17:18:56 host audit[7643]: AVC apparmor=“DENIED” operation=“open” profile=“/usr/bin/whonixcheck” name=“/etc/security/access-security-misc.conf” pid=7643 comm=“sudo” requested_mask=“r” denied_mask=“r” fsuid=0 ouid=0
Dec 10 17:18:56 host audit[7643]: SYSCALL arch=c000003e syscall=257 success=no exit=-13 a0=ffffff9c a1=5686851ff273 a2=0 a3=0 items=1 ppid=7642 pid=7643 auid=4294967295 uid=1000 gid=1000 euid=0 suid=0 fsuid=0 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=4294967295 comm=“sudo” exe=“/usr/bin/sudo” subj==/usr/bin/whonixcheck (enforce) key=(null)
Dec 10 17:18:56 host audit: CWD cwd=“/”
Dec 10 17:18:56 host audit: PATH item=0 name=“/etc/security/access-security-misc.conf” inode=140805 dev=ca:03 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0
Dec 10 17:18:56 host audit: PROCTITLE proctitle=7375646F002D2D6E6F6E2D696E746572616374697665002D750077686F6E6978636865636B002F7573722F6C69622F77686F6E6978636865636B2F77686F6E6978636865636B002D2D6461656D6F6E002D2D677569002D2D636C69
Dec 10 17:18:56 host sudo[7643]: pam_access(sudo:account): failed to open accessfile=[/etc/security/access-security-misc.conf]: Permission denied
Dec 10 17:18:56 host sudo[7643]: pam_access(sudo:account): failed to parse the module arguments

Need to add /etc/security/access-security-misc.conf to apparmor abstractions/base?

[Patrick]

This is also broken:

Kicksecure/sdwdate-gui/blob/master/etc/qubes-rpc/whonix.NewStatus

Dec 10 16:42:49 host sudo[7369]: pam_access(sudo:account): access denied for user user' from ’
Dec 10 16:42:49 host sudo[7369]: user : PAM account management error: Permission denied ; TTY=unknown ; PWD=/home/user ; USER=sdwdate-gui ; COMMAND=/usr/bin/bash -c echo “disp3655” | tee /run/sdwdate-gui/anon-status >/dev/null

/etc/pam.d/sudo should probably not use pam_access. But due to how /usr/share/pam-configs works, I don’t see how it could apply to /etc/pam.d/login only. Would require writing to /etc/pam.d/login directly which is bad.