Skip to content

Development VMs

Jump to bottom
TPArchambault edited this page Dec 17, 2021 · 8 revisions

Using scripted VMs as development environments

Creating the development VMs

To create a Fedora 34 development environment, go to the scripts/vagrant/fc34 directory in this repo and issue the command:

ENV="dev" vagrant up

To create a RedHat Enterprise Linux 8 (RHEL8) development environment, go to the scripts/vagrant/rhel8 directory in this repo and issue the command:

export RHSM_USERNAME="<USERNAME-HERE>"
export RHSM_PASSWORD="<PASSWORD-HERE>"
ENV="dev" vagrant up

Be sure to populate the environment variables RHSM_USERNAME and RHSM_PASSWORD with your RedHat subscription credentials prior to running vagrant up in this directory. If you don't have a RedHat account, you can get one for free here.

Development using the VMs

The VMs are using a host-side persisted shared folder called .shared that resides in the folder where vagrant was run. Inside the VM, this folder is mounted to /shared. In this shared folder is a vagrant/git/fapolicy-analyzer folder where the source repository is cloned and the origin/master branch is checked out and built by default. If a branch other than origin/master is desired, you can use the environment variable GIT_BRANCH when doing a vagrant up or vagrant provision and the branch indicated will be checked out and built instead. When logging in as the vagrant user, from the vagrant home direcory, there is a git symlink that will take you to /shared/vagrant/git, then from there is a folder called fapolicy-analyzer where development and testing can take place. Typically I like to use a IDE on my host system (vscode) to make changes and then inside the VM, do the building and testing. From the host machine, you can use git to pull and push code into and from the .shared directory. I prefer to treat my development and testing environment like cattle rather than pets and have gotten a lot of milage doing so.

Rebuilding

From the top of the repo in the VM:

pipenv install --dev
pipenv run python setup.py develop

Running the fapolicy_analyzer UI

From the top of the repo in the VM:

pipenv run python -m fapolicy_analyzer.ui

Vagrant Automated Demo Installation and Event Generation Scenarios

The current vagrant/ansible scripting runs a vagrant VM instance through a number of user scenarios that generate fapolicyd events that are captured within the logs. (The ansible playbooks are located under fapolicy-analyzer/scripts/demo/)

The following is a summary of the automated demo set-up and event generation.

Prepare Systems, Users, Groups

  • Configure OS platforms
  • Create users and groups; populate groups:
    • Groups:
      • accountant
      • developer
      • sysadmin
    • Users (all are in 'user' group)
      • bob
      • alice
      • carol
      • dave (developer group)
      • eve
      • mallory
      • trudy (sysadmin group)

fapolicyd installation and configuration

  • Basic install, customized config, rules, trust
  • Start the daemon

Modify the filesystem

  • Create and populate the /demo directory with a copy of the 'ls' executable, renamed as my-ls.
  • Download and install untrusted statically linked functional replacement executables for:
    • /usr/bin/du (dust -> du)
    • /usr/bin/cat (bat -> cat)
    • /demo/my-echo (printr -> echo functional equivalent)
    • /usr/bin/grep (rg -> grep)
  • Copy files into the filesystem independent of an rpm installation i.e. they are not in the system trust database.
    • /tmp/fapolicyd-readme.md
    • /usr/local/bin/dbadmin.py
  • User 'dave' of the 'developer' group performs a user local installation of the rust tool suite.

Simulate user workflows to generate fapolicyd events

  • The users alice, carol, eve, trudy, (if fapd is executing, unsuccessfully) attempt to execute the untrusted 'du' command, du /tmp
  • The users alice, carol, mallory, trudy, successfully execute:
$ ls /tmp
$ df -h
$ which nano
  • Similarly, the full user set of alice, bob, carol, dave, eve, mallory, trudy, (if fapd is executing, unsuccessfully) attempt to execute:
$ echo foo | grep foo

which is denied because the grep command has been replaced and is untrusted or there is a cksum discrepancy.

  • The regular user, 'alice' will repeatedly invoke the replaced /usr/bin/du command with a number of arguments. Note that all arguments are fully trusted except for /usr/bin/grep which has been replaced with a statically linked binary.
    • /sbin/tcpdump
    • /usr/bin/bash
    • /usr/bin/curl
    • /usr/bin/firefox
    • /usr/bin/gcc
    • /usr/bin/grep
    • /usr/bin/python
  • User 'alice' executes the untrusted /usr/local/bin/dbadmin.py
  • User 'dave' attempts to execute his user installed rust compiler, /home/dave/.cargo/bin/rustc.
  • Finally fapolicyd events are extracted for the journalctl log and saved as /home/vagrant/events-1.txt
Clone this wiki locally