|Summary:||dconf db is not checked by OVAL|
|Product:||Red Hat Enterprise Linux 7||Reporter:||Marek Haicman <mhaicman>|
|Component:||scap-security-guide||Assignee:||Matěj Týč <matyc>|
|Status:||CLOSED ERRATA||QA Contact:||Matus Marhefka <mmarhefk>|
|Severity:||high||Docs Contact:||Mirek Jahoda <mjahoda>|
|Version:||7.6||CC:||ggasparb, jcerny, matyc, mhaicman, mjahoda, mthacker, openscap-maint, wsato|
|Fixed In Version:||scap-security-guide-0.1.43-13.el7||Doc Type:||Bug Fix|
.`SCAP Security Guide` now correctly checks the `dconf` configuration Prior to this update, OVAL (Open Vulnerability and Assessment Language) checks used in the `SCAP Security Guide` project did not check the `dconf` binary database directly, but it checked only the respective key files. This could lead to false positives or negatives in scanning results. With this update, `SCAP Security Guide` adds one more check component, which ensures that the `dconf` binary database is up-to-date with regards to those key files. As a result, the complex check now checks the `dconf` configuration correctly.
|Last Closed:||2019-08-06 13:04:08 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description Marek Haicman 2018-09-20 12:53:35 UTC
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): scap-security-guide-0.1.36-9.el7_5.noarch How reproducible: reliably 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: [org/gnome/login-screen] banner-message-enable=true 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 Actual results: 3. pass 5. pass 7. pass Expected results: 3. fail 5. pass 7. fail Additional info: Due to OVAL design, we need to either have dconf probe, or dbus probe to truly solve the problem.
Comment 2 Marek Haicman 2018-09-20 13:23:58 UTC
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?
Comment 3 Ray Strode [halfline] 2018-09-27 11:57:10 UTC
hey sorry for the slow response on this. dconf can be configured to use text based keyfiles as it's data backend: https://help.gnome.org/admin/system-admin-guide/stable/dconf-nfs-home.html.en 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.
Comment 8 Watson Yuuma Sato 2019-02-25 08:51:50 UTC
Fixed by upstream in https://github.com/ComplianceAsCode/content/pull/3725 And improved user experience in https://github.com/ComplianceAsCode/content/pull/3755
Comment 11 Gabriel Gaspar Becker 2019-05-13 14:07:39 UTC
Results for verifying the bug: RHEL Version: RHEL-7.7-20190502.1 Package version: rpm -qa scap-security-guide scap-security-guide-0.1.43-4.el7.noarch Found issues: 1. Fresh installation doesn't contain system-db:gdm under /etc/dconf/profile/user file so configuration is not applied when reproducing the bug. $cat /etc/dconf/profile/user user-db:user system-db:local system-db:site system-db:distro - 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: system-db:gdm - 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: https://developer.gnome.org/dconf/unstable/dconf-overview.html "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 Empty results ---------------------------- Proposed solution does not fix all the issues. Moving issue status back to ASSIGNED.
Comment 12 Matěj Týč 2019-05-13 15:19:15 UTC
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.
Comment 13 Ray Strode [halfline] 2019-05-13 20:05:54 UTC
/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.
Comment 17 Matěj Týč 2019-06-03 15:29:55 UTC
Comment 22 Matěj Týč 2019-06-12 15:47:23 UTC
Comment 31 errata-xmlrpc 2019-08-06 13:04:08 UTC
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. https://access.redhat.com/errata/RHBA-2019:2198