When looping a directory it's best to consolidate the find command as much as possible so as not to have a long running control. Preferable to add the -maxdepth 0 with the max directory depth you require as well as -xdev options.

Controls are written expecting a 64bit architecture. Consider having an 'input' or else statements in the controls to test if they use a 32bit architecture instead.

Controls affected:

1. • V-75605
2. • V-75607
3. • V-75609
4. • V-75689
5. • V-75717
6. • V-75719
7. • V-75721
8. • V-75723
9. • V-75725
10. • V-75727
11. • V-75729
12. • V-75731
13. • V-75733
14. • V-75735
15. • V-75737
16. • V-75739
17. • V-75741
18. • V-75743
19. • V-75745
20. • V-75747
21. • V-75749
22. • V-75751
23. • V-75753
24. • V-75791
25. • V-75793
26. • V-75795

This will help ensure that JSONs are clearly linked to the PRs and builds they come from

Our convention is vendor-product-version-edition[-stig|cis]-baseline

So the name should be:
canonical-ubuntu-16.04-lts-stig-baseline

Align to this template please: https://github.com/mitre/docs-mitre-inspec/blob/master/templates/baseline_readme.md

Created a pull-request with the fixes
#29

The check and text on V-75393 is incorrect:

V-75393 is the check for banner text.

see: https://docs.travis-ci.com/user/uploading-artifacts/

Running rubocop syntax checker found the following issues:

rubocop.txt

In V-75469 there is the following block of code:

    describe 'Emergency accounts' do
      it { should be_empty }
    end

and similarly in V-75491:

    describe 'Temporary accounts' do
      it { should be_empty }
    end

These blocks cause unreadable failure messages, such as:
expected "Emergency accounts".empty? to be truthy, got false

Depending on the intent of the code, a fix may be to check if the input arrays are empty.

Add capability to parameterize emergency account expiry check in https://github.com/mitre/canonical-ubuntu-16.04-lts-stig-baseline/blob/development/controls/V-75469.rb

We are borrowing form the RHEL stig on this which uses an effective but possibly outdated method of testing. We will allow this for now but in the end I would like this to be reviewed and enhanced on our Peer Review.

Control list with comments that need to be removed:

• V-75445
• V-75517
• V-75523
• V-75527
• V-75535
• V-75555
• V-75571
• V-75573
• V-75587
• V-75661
• V-75663
• V-75665
• V-75667
• V-75687
• V-75691
• V-75693
• V-75695
• V-75697
• V-75699
• V-75707
• V-75709
• V-75711
• V-75713
• V-75715
• V-75755
• V-75757
• V-75759
• V-75761
• V-75765
• V-75767
• V-75769
• V-75771
• V-75773
• V-75775
• V-75777
• V-75779
• V-75781
• V-75783
• V-75785
• V-75787
• V-75789
• V-75825
• V-78007
• V-80969

It looks like attributes are used, such as temporary account lists. Ensure that these and others are included in inspec.yml and the README (for user-defined).

Running inspec check on the profile came up with these results:

For control V-75437 the logic goes like this:

gnome_installed = (package('ubuntu-gnome-desktop').installed? || package('ubuntu-desktop').installed?)

  if gnome_installed
    lock_enabled = command('gsettings get org.gnome.desktop.screensaver lock-enabled')
    describe lock_enabled do
      its('stdout') { should cmp 'true' }
    end
  else
    describe "Not Applicable as GNOME dekstop environment is installed" do
      subject { gnome_installed }
      it { should be false }
    end
  end
end

If you run into a Not Applicable scenario as you do in your else block, we want the impact to be 0 as this check is not applicable to the environment. So make sure to add a line impact 0 within that else block to update the impact score.

Create sample data folder and put output results of the profile for an unhardened and hardened box.