Description of problem:
Rules that check for GNOME dconf configuration are reading and enforcing content of configuration files on the file system in `/etc/dconf/` directory tree. That content is only prescription for `dconf update` to fill in the binary dconf GVariant database. At the moment, there is no OVAL check to verify contents of the real binary DB. So OpenSCAP scanner using SCAP Security Guide cannot identify if the machine is hardened or not.
So "pass" is possibly false negative.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
0. let's use this rule https://static.open-scap.org/ssg-guides/ssg-rhel7-guide-C2S.html#xccdf_org.ssgproject.content_rule_dconf_gnome_banner_enabled
1. yum install openscap-scanner scap-security-guide
2. Follow the guide, so add or edit `banner-message-enable=true` to /etc/dconf/db/gdm.d/00-security-settings:
2a. Add `/org/gnome/login-screen/banner-message-enable` to `/etc/dconf/db/gdm.d/locks/00-security-settings-lock`
3. run scan `oscap xccdf eval --profile C2S --rule xccdf_org.ssgproject.content_rule_dconf_gnome_banner_enabled /usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml
4. run `dconf update`
5. repeat #3
6. run `dconf write org/gnome/login-screen/banner-message-enable false`
7. repeat #3
Due to OVAL design, we need to either have dconf probe, or dbus probe to truly solve the problem.
Hello Ray, do you have any tips that could work regarding this issue? Basically - in OVAL, we currently have no option to communicate over dbus, or execute commands. Our best bet is reading files on the file system. Is there a way dconf can show db contents continuously on FS? Or are dbus and dconf command line the only ways to get the contents?
hey sorry for the slow response on this.
dconf can be configured to use text based keyfiles as it's data backend:
but that's not the recommended default. It's main purpose is to provide better reliability over NFS.
Note, dconf doesn't use dbus for *reading*. it only uses dconf for writing. so it should be possible to monitor the database if you can add a runtime dependency to libdconf.
Fixed by upstream in https://github.com/ComplianceAsCode/content/pull/3725
And improved user experience in https://github.com/ComplianceAsCode/content/pull/3755
Results for verifying the bug:
rpm -qa scap-security-guide
1. Fresh installation doesn't contain system-db:gdm under /etc/dconf/profile/user file so configuration is not applied when reproducing the bug.
- There is no gdm entry listed, so configuration under /etc/dconf/db/gdm.d/ directory won't be taken into consideration.
- This is probably a bug in gdm's package because this directory is created by gdm package and it should update /etc/dconf/profile/user file with a new entry such as:
- one solution is to check if system-db:gdm is present on /etc/dconf/profile/user so the configuration is actually applied, create the entry if doesn't exist.
2. If system-db:gdm is set, and the lock file exists; it is not possible to execute dconf write for this configuration as described in the reproducer because it is blocked for writing.
3. When the remediation for dbconf_use_text_backend is applied, it is required to restart the session so the text backend starts to work properly, this needs to put in sync with the rules which touch dconf's database.
4. The configuration needs to be read from something like /root/.config/dconf/user.txt as per:
"A typical line is service-db:keyfile/user, which tells dconf to synchronize the binary database with a plain text keyfile in $XDG_CONFIG_HOME/dconf/user.txt. The synchronization is bi-directional."
This implies that the OVAL check for dconf_gnome_banner_enabled and similar rules should be changed to check the configuration from this file.
$cat ssg-rhel7-xccdf.xml | grep user.txt
Proposed solution does not fix all the issues. Moving issue status back to ASSIGNED.
For reference, the findings in the comment above can be rephrased in the following way:
1. The text message that GDM is supposed to show is specified to a file under the /etc/dconf/db/gdm.d directory.
The file won't be taken into account, unless /etc/dconf/profile/user contains the according system-db:gdm configuration item.
2. If the user attempts to change the message by changing files under the /etc/dconf/db/gdm.d directory,
it is going to be ignored in favor of $XDG_CONFIG_HOME/dconf/user.txt, which gets created/updated by the dconf binary.
Therefore, with current remediation/OVAL combination, one can easily end up with false negative.
Moreover, the remediation requires gdm restart.
/etc/dconf/profile/user should never contain system-db:gdm. system-db:gdm is for the login screen settings, not user settings.
user session settings should be set in /etc/dconf/db/local.d or /etc/dconf/db/site.d or /etc/dconf/db/distro.d (or use gsettings overrides)
/usr/share/dconf/profile/gdm should contain system-db:gdm , though.
See also bug 1664284 where we neglected to create the directory /etc/dconf/db/gdm.d on behalf of the admin.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.