Bug 1631378
| 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> |
| Priority: | high | ||
| Version: | 7.6 | CC: | ggasparb, jcerny, matyc, mhaicman, mjahoda, mthacker, openscap-maint, wsato |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | scap-security-guide-0.1.43-13.el7 | Doc Type: | Bug Fix |
| Doc Text: |
.`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.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-08-06 13:04:08 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1648377 | ||
|
Description
Marek Haicman
2018-09-20 12:53:35 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? 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. 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: 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. 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. https://access.redhat.com/errata/RHBA-2019:2198 |