2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2020

06/20/2020: Running OPENSCAP (OSCAP) on Fedora CoreOS

I am exploring how to create a Fedora CoreOS server that can pass as many security checks as possible. However, I am not a security guru. Make sure to vet anything you read here with your own experts.

This work is being done at the request of the Enterprise Container Working Group (ECWG) of the Office of Information and Technology (OIT - https://www.oit.va.gov/) at the Department of Veteran Affairs.


Run oscap on a Fedora CoreOS server.


Fedora CoreOS is an automatically-updating, minimal operating system for running containerized workloads securely and at scale. However, we’ll probably be replacing virtual servers instead of updating them.

OpenSCAP is an ecosystem providing multiple tools to assist administrators and auditors with assessment, measurement, and enforcement of security baselines. SCAP or Security Content Automation Protocol is a U.S. standard maintained by National Institute of Standards and Technology (NIST).

rpm-ostree - rpm-ostree is a hybrid image/package system. It uses libOSTree as a base image format, and accepts RPM on both the client and server side, sharing code with the dnf project

XCCDF - XCCDF is a specification language for writing security checklists, benchmarks, and related kinds of documents. An XCCDF document represents a structured collection of security configuration rules for some set of target systems.


The first step is to install the software.

sudo rpm-ostree install openscap-scanner scap-security-guide zip
sudo reboot

Of note is that the installation provides the following files.

$ ls -c1  /usr/share/xml/scap/ssg/content/*fedora*.xml

I don’t yet know how they are used, but the XCCDF file looks promising. We can find more information. The profiles are relevant, I think.

$ oscap info /usr/share/xml/scap/ssg/content/ssg-fedora-xccdf.xml
Document type: XCCDF Checklist
Checklist version: 1.1
Imported: 1970-01-01T00:00:00
Status: draft
Generated: 2020-06-03
Resolved: true
	Title: OSPP - Protection Profile for General Purpose Operating Systems
		Id: ospp
	Title: PCI-DSS v3 Control Baseline for Fedora
		Id: pci-dss
	Title: Standard System Security Profile for Fedora
		Id: standard
Referenced check files:
		system: http://oval.mitre.org/XMLSchema/oval-definitions-5
		system: http://scap.nist.gov/schema/ocil/2

Run Evaluation

Let’s use the standard profile to run an evaluation. I change the ownership of the result files so that I can scp them to my local workstation.

sudo oscap xccdf eval \
    --profile standard \
    --fetch-remote-resources \
    --report xccdf-report.html \
    --results ssg-fedora-xccdf-results.xml \

sudo chown core:core xccdf-report.html ssg-fedora-xccdf-results.xml

Open the HTML file in a web broswer to view the results.

Generate Fixes

oscap has a wonderful feature to suggest fixes. The following command does this. It does not need to be run as root. If you prefer a different fix-type, use --help to learn how.

oscap xccdf generate fix \
    --fix-type ansible \
    --output playbook-xccdf-fixes.yml \
    --profile standard \

Right off the bat, I needed to add to the playbook.

    become: yes

        ansible_python_interpreter: '/usr/bin/python3'

These changes allowed the playbook to get started but it wasn’t long before the first task failure. That’s tale for another time.

Generate Guide

oscap xccdf generate guide \
    --profile standard \
    --output xccdf-guide.html \

06/12/2020: Add AWS SSM Agent on Fedora CoreOS


This work is being done at the request of the Enterprise Container Working Group (ECWG) of the Office of Information and Technology (OIT - https://www.oit.va.gov/) at the Department of Veteran Affairs.


This article shows how to install the AWS SSM Agent on Fedora CoreOS. My goal was to alert when ‘denied’ messages appear in audit logs. My first step towards this goal was to install the SSM agent to allow the server’s /var/log/audit/audit.log file to appear in the CloudWatch Logs console.

After I did this work, I realized that I should have started with the CloudWatch agent. Ah well.

The first step is entirely in your hands. Clone https://github.com/aws/amazon-ssm-agent.git and build the binary files. Whatever directory you use will become the ssm_binary_dir in the ansible command.

The ansible-playbook command looks like this. core is the ssh user for Fedora CoreOS.

python3 ansible-playbook \
  --extra-vars ssm_binary_dir=/data/projects/amazon-ssm-agent/bin \
  -i inventory \
  -u core \

Define an inventory file with the IP address of the remote server.

cat <<EOF > inventory

I add the PEM file to SSH to simplify my life. I learned that having PEM files in ~/.ssh slows the connection process and can cause trouble if there are too many. That’s I am using my Downloads directory.

ssh-add /home/medined/Downloads/ec2-key-pair.pem

Now here is the playbook.

cat <<EOF > playbook.aws-ssm-agent.yml
- hosts: fcos
  gather_facts: false

    ansible_python_interpreter: '/usr/bin/python3'


  # ##########
  # # Amazon SSM Agent
  # ##########

  - name: Copy Amazon SSM Agent
    become: yes
      src: ""
      dest: /usr/local/bin
      mode: 755
      force: no
      - "/linux_amd64/*"

  - name: Make logging directory
    become: yes
      path: /var/log/amazon/ssm
      state: directory

  - name: Make config directory
    become: yes
      path: /etc/amazon/ssm
      state: directory

  - name: Copy Amazon SSM Agent JSON
    become: yes
      src: "/amazon-ssm-agent.json.template"
      dest: /etc/amazon/ssm/amazon-ssm-agent.json

  - name: Copy Amazon SSM Agent JSON
    become: yes
      src: "/seelog_unix.xml"
      dest: /etc/amazon/ssm

  - name: Create SSM service file.
    become: yes
      dest: /etc/systemd/system/amazon-ssm-agent.service
      content: |

  - name: Enable SSM service
    become: yes
      name: amazon-ssm-agent
      enabled: yes
      state: started

You now have all of the pieces to deploy the AWS SSM Agent on Fedora CoreOS.