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

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

1 Like

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.

2 Likes

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?

1 Like

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.

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

(commented out by Debian default)

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


pam_securetty

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:

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

1 Like

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

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

2 Likes

2 posts were split to a new topic: pam_namspace / namespace.conf to gie user own private /tmp

It’s implemented.

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.

2 Likes

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

1 Like

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?

1 Like

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

@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?

1 Like

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

2 Likes

Network namespaces?

2 Likes

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

1 Like

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.

2 Likes

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.

2 Likes

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:

Which is limited.

Did that.

2 Likes

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

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?

1 Like

This is also broken:

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.

1 Like