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

Development
,
13

Network namespaces?

2 Likes
14

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

1 Like
15

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
16

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
17

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

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
20

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
21

Why is whonixcheck trying to access it? Why not just add it to the whonixcheck profile?

Maybe this would work:

Conflicts: sudo
1 Like
22

Ah, the issue isn’t /etc/pam.d/sudo but /etc/pam.d/common-account (which sudo has an include rule for).

1 Like
23

It’s not. But it uses sudo. And then pam calls it.

It’s just a symptom. Would be happening with other applications too.

Exactly.

1 Like
24

Then it should be added to the base abstraction.

25

Found a potential solution. Using pam_exec, environment variable PAM_SERVICE, exit codes (depending on if PAM_SERVICE is set to login) and then using the /etc/pam.d feature “jumping over the next N modules in the stack”.

That probably means just that when users run sudo pam-auth-update that they cannot enable two conflicting pam modules at the same time.

1 Like
26
1 Like
27

use pam_acccess only for /etc/pam.d/login
remove Allow members of group 'ssh' to login.
remove +:ssh:ALL EXCEPT LOCAL

The SSH restrictions earlier was just a byproduct of not knowing how to implement this better, i.e like how it is implemented now. Now this is effectively only used for /etc/pam.d/login.

Does pam_access line

+:ssh:ALL EXCEPT LOCAL

make sense for /etc/pam.d/ssh or should pam_access be used for any other services in /etc/pam.d folder too?

1 Like
28
1 Like
29
1 Like
30

Why don’t we allow group members of group sudo to use console by editing /etc/security/access-security-misc.conf ? Group members of group sudo could run sudo addgroup user console anyhow. Therefore no security advantage by not doing that.

Did that:

Review for full file welcome:

security-misc/etc/security/access-security-misc.conf at master · Kicksecure/security-misc · GitHub

1 Like
31

@Patrick, there are syntax errors in the file. Groups should be surrounded with “(group)” instead of as “group”. It works as is unless any users with the same name as the groups are created. See access.conf to verify. I fixed it for you.

line 30: +:(console):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 ttyS0 ttyS1 ttyS2 ttyS3 ttyS4 ttyS5 ttyS6 ttyS7 ttyS8 ttyS9

line 34: +:(sudo):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 ttyS0 ttyS1 ttyS2 ttyS3 ttyS4 ttyS5 ttyS6 ttyS7 ttyS8 ttyS9

line 38: -:ALL EXCEPT (console-unrestricted):ALL

2 Likes
32

Thanks. Good catch. Fixed.

1 Like