Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 1631378 - dconf db is not checked by OVAL [NEEDINFO]
dconf db is not checked by OVAL
Status: NEW
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: scap-security-guide (Show other bugs)
7.6
Unspecified Unspecified
high Severity high
: rc
: ---
Assigned To: Watson Yuuma Sato
BaseOS QE Security Team
Mirek Jahoda
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2018-09-20 08:53 EDT by Marek Haicman
Modified: 2018-10-31 19:50 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Known Issue
Doc Text:
*dconf* databases are not checked by OVAL OVAL (Open Vulnerability and Assessment Language) checks used in the *SCAP Security Guide* project are not able to read a *dconf* binary database, only files used to generate the database. The database is not regenerated automatically, the administrator needs to enter the "dconf update" command. As a consequence, changes to the database that are not reflected in files in the `/etc/dconf/db/` directory cannot be a part of scanning. This might result in false negatives. To work around this problem, run "dconf update" periodically, for example, using the `/etc/crontab` configuration file.
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
mjahoda: needinfo? (wsato)


Attachments (Terms of Use)

  None (edit)
Description Marek Haicman 2018-09-20 08:53:35 EDT
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 09:23:58 EDT
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 07:57:10 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.