- 필수 기능
- 시작하기
- Glossary
- 표준 속성
- Guides
- Agent
- 통합
- 개방형텔레메트리
- 개발자
- API
- Datadog Mobile App
- CoScreen
- Cloudcraft
- 앱 내
- 서비스 관리
- 인프라스트럭처
- 애플리케이션 성능
- APM
- Continuous Profiler
- 스팬 시각화
- 데이터 스트림 모니터링
- 데이터 작업 모니터링
- 디지털 경험
- 소프트웨어 제공
- 보안
- AI Observability
- 로그 관리
- 관리
By default, DConf uses a binary database as a data backend. The system-level database is compiled from keyfiles in the /etc/dconf/db/ directory by the
dconf update
command. More specifically, content present in the following directories:
/etc/dconf/db/gdm.d
/etc/dconf/db/local.d
Unlike text-based keyfiles, the binary database is impossible to check by OVAL. Therefore, in order to evaluate dconf configuration, both have to be true at the same time - configuration files have to be compliant, and the database needs to be more recent than those keyfiles, which gives confidence that it reflects them.
The following script can be run on the host to remediate the issue.
#!/bin/bash
# Remediation is applicable only in certain platforms
if rpm --quiet -q gdm && { [ ! -f /.dockerenv ] && [ ! -f /run/.containerenv ]; }; then
dconf update
else
>&2 echo 'Remediation is not applicable, nothing was done'
fi
The following playbook can be run with Ansible to remediate the issue.
- name: Gather the package facts
package_facts:
manager: auto
tags:
- CCE-81004-4
- PCI-DSS-Req-6.2
- PCI-DSSv4-8.2.8
- dconf_db_up_to_date
- high_severity
- low_complexity
- medium_disruption
- no_reboot_needed
- unknown_strategy
- name: Run dconf update
ansible.builtin.command:
cmd: dconf update
when:
- '"gdm" in ansible_facts.packages'
- ansible_virtualization_type not in ["docker", "lxc", "openvz", "podman", "container"]
tags:
- CCE-81004-4
- PCI-DSS-Req-6.2
- PCI-DSSv4-8.2.8
- dconf_db_up_to_date
- high_severity
- low_complexity
- medium_disruption
- no_reboot_needed
- unknown_strategy