Hide userlist in GDM, is that a control?

[Thulium-Drake]

Question While looking into the rules for GDM (to debug a different issue) the following question arose:

Why doesn't GDM hide all users that previously logged in? Is that simply not a CIS control?

It seems weird to me, as it's a form of information leakage :-)

In any case, if you need some code to set that up:

---
- name: 'Ensure dconf profile'
  ansible.builtin.copy:
    dest: '/etc/dconf/profile/gdm'
    owner: 'root'
    group: 'root'
    mode: 0644
    content: |
      # This file is managed by Ansible, YOUR CHANGES WILL BE LOST!
      user-db:user
      system-db:gdm
      file-db:/usr/share/gdm/greeter-dconf-defaults

- name: 'Ensure GDM keyfile'
  ansible.builtin.copy:
    dest: '/etc/dconf/db/gdm.d/00-login-screen'
    owner: 'root'
    group: 'root'
    mode: 0644
    content: |
      # This file is managed by Ansible, YOUR CHANGES WILL BE LOST!
      [org/gnome/login-screen]
      # Do not show the user list
      disable-user-list=true

- name: 'Update dconf database'
  ansible.builtin.command: dconf update
  changed_when: false

[georgenalen]

@Thulium-Drake, I have to dig a bit more, but on first scan through the CIS I'm not seeing a control that would be for that scenario. It's a good scenario to catch and that is somewhat the downside to the benchmark checklist type of securing a system. You shouldn't just go through the checklist of the standard and say it conforms, all is good. It misses a lot, is brittle in certain ways, etc., so basically it's a good starting point to securing a system they aren't super great.

With the role itself the goal is to apply the CIS benchmark controls (or STIG on those ones) and we try to keep the role to only do/change what the benchmark tells us to do, or what the intent of the control is (they sometimes have incomplete or wrong fix text for what they want to accomplish). Then we write the role in a way that is easy to add into other automation playbooks/collections/roles you have locally to better secure the system and whatever else you are automating. This means the only thing this role will do is the controls that are located in the CIS (or STIG).

I'm going to leave this ticket open until I finish doing a more in-depth check to see if there is a control where the intent was what you mentioned but it was somewhat buried in the documentation.

-George

[Thulium-Drake]

Hi George,

Thanks for looking into this! I wanted to do it myself, but it seems the CIS docs aren't publicly available (and the mailform didn't work for me :( ).

Your stance makes sense, stick to what the docs want, or run the risk of an ever-expanding scope.

Thanks for all the great work ;-)

[georgenalen]

Closing this one due to being a bit stale. Also @Thulium-Drake here is the only link we really have access to as well. It has jus the simple benchmark pdf. I'm not sure if that's where you are getting the benchmarks from or not, but that's at least the place we pull ours from.

https://downloads.cisecurity.org/#/

[Thulium-Drake]

Thanks for the link! :D