major.io

Words of wisdom from a Linux engineer focused on information security

major.io

Words of wisdom from a systems engineer

Creative Commons License

Apply the STIG to even more operating systems with ansible-hardening

By Leave a Comment

FortressTons of improvements made their way into the ansible-hardening role in preparation for the OpenStack Pike release next month. The role has a new name, new documentation and extra tests.

The role uses the Security Technical Implementation Guide (STIG) produced by the Defense Information Systems Agency (DISA) and applies the guidelines to Linux hosts using Ansible. Every control is configurable via simple Ansible variables and each control is thoroughly documented.

These controls are now applied to an even wider variety of Linux distributions:

  • CentOS 7
  • Debian 8 Jessie (new for Pike)
  • Fedora 25 (new for Pike)
  • openSUSE Leap 42.2+ (new for Pike)
  • Red Hat Enterprise Linux 7
  • SUSE Linux Enterprise 12 (new for Pike)
  • Ubuntu 14.04 Trusty
  • Ubuntu 16.04 Xenial

Any patches to the ansible-hardening role are tested against all of these operating systems (except RHEL 7 and SUSE Linux Enterprise). Support for openSUSE testing landed this week.

Work is underway to put the finishing touches on the master branch before the Pike release and we need your help!

If you have any of these operating systems deployed, please test the role on your systems! This is pre-release software, so it’s best to apply it only to a new server. Read the “Getting Started” documentation to get started with ansible-galaxy or git.

Photo credit: Wikipedia

Customize LDAP autocompletion format in Thunderbird

By Leave a Comment

MailboxThunderbird can connect to an LDAP server and autocomplete email addresses as you type, but it needs some adjustment for some LDAP servers. One of the LDAP servers that I use regularly returns email addresses like this in the thunderbird interface:

The email address looks fine, but I’d much rather have the person’s full name instead of the username. Here’s what I’m looking for:

In older Thunderbird versions, setting ldap_2.servers.SERVER_NAME.autoComplete.nameFormat to displayName was enough. However, this option isn’t used in recent versions of Thunderbird.

Digging in

After a fair amount of searching the Thunderbird source code with awk, I found a mention of DisplayName in nsAbLDAPAutoCompleteSearch.js that looked promising:

Something is unusual here. The LDAP field is called displayName, but this attribute is called DisplayName (note the capitalization of the D). Just before that line, I see a lookup in an attributes map of some sort. There may be a configuration option that is called DisplayName.

In Thunderbird, I selected Edit > Preferences. I clicked the Advanced tab and then Config Editor. A quick search for DisplayName revealed an interesting configuration option:

Fixing it

That’s the problem! This needs to map to displayName in my case, and not cn,commonname (which returns a user’s username). There are two different ways to fix this:

After making the change, quit Thunderbird and relaunch it. Compose a new email and start typing in the email address field. The user’s first and last name should appear!

Old role, new name: ansible-hardening

By 2 Comments

The interest in the openstack-ansible-security role has taken off faster than I expected, and one piece of constant feedback I received was around the name of the role. Some users were unsure if they needed to use the role in an OpenStack cloud or if the OpenStack-Ansible project was required.

ansible-hardening logoThe role works everywhere — OpenStack cloud or not. I started a mailing list thread on the topic and we eventually settled on a new name: ansible-hardening! The updated documentation is already available.

The old openstack-ansible-security role is being retired and it will not receive any additional updates. Moving to the new role is easy:

  1. Install ansible-hardening with ansible-galaxy (or git clone)
  2. Change your playbooks to use the ansible-hardening role

There’s no need to change any variable names or tags — they are all kept the same in the new role.

As always, if you have questions or comments about the role, drop by #openstack-ansible on Freenode IRC or open a bug in Launchpad.

Enable AppArmor on a Debian Jessie cloud image

By 2 Comments

Armor from the middle ages makes sense when you're talking about AppArmor, right?I merged some initial Debian support into the openstack-ansible-security role and ran into an issue enabling AppArmor. The apparmor service failed to start and I found this output in the system journal:

Digging in

That was unexpected. I was using the Debian jessie cloud image and it uses extlinux as the bootloader. The file didn’t reference AppArmor at all:

I learned that AppArmor is disabled by default in Debian unless you explicitly enable it. In contrast, SELinux is enabled unless you turn it off. To make matters worse, Debian’s cloud image doesn’t have any facilities or scripts to automatically update the extlinux configuration file when new kernels are installed.

Making a repeatable fix

My two goals here were to:

  1. Ensure AppArmor is enabled on the next boot
  2. Ensure that AppArmor remains enabled when new kernels are installed

The first step is to install grub2:

During the installation, a package configuration window will appear that asks about where grub should be installed. I selected /dev/vda from the list and waited for apt to finish the package installation.

The next step is to edit /etc/default/grub and add in the AppArmor configuration. Adjust the GRUB_CMDLINE_LINUX_DEFAULT line to look like the one below:

Ensure that the required AppArmor packages are installed:

Enable the AppArmor service upon reboot:

Run update-grub and reboot. After the reboot, run apparmor_status and you should see lots of AppArmor profiles loaded:

Final thoughts

I’m still unsure about why AppArmor is disabled by default. There aren’t that many profiles shipped by default (38 on my freshly installed jessie system versus 417 SELinux policies in Fedora 25) and many of them affect services that wouldn’t cause significant disruptions on the system.

There is a discussion that ended last year around how to automate the AppArmor enablement process when the AppArmor packages are installed. This would be a great first step to make the process easier, but it would probably make more sense to take the step of enabling it by default.

Photo credit: Max Pixel

Fixing OpenStack noVNC consoles that ignore keyboard input

By Leave a Comment

Televideo consoleI opened up a noVNC console to a virtual machine today in my OpenStack cloud but found that the console wouldn’t take keyboard input. The Send Ctrl-Alt-Del button in the top right of the window worked just fine, but I couldn’t type anywhere in the console. This happened on an Ocata OpenStack cloud deployed with OpenStack-Ansible on CentOS 7.

Test the network path

The network path to the console is a little deep for this deployment, but here’s a quick explanation:

  • My laptop connects to HAProxy
  • HAProxy sends the traffic to the nova-novncproxy service
  • nova-novncproxy connects to the correct VNC port on the right hypervisor

If all of that works, I get a working console! I knew the network path was set up correctly because I could see the console in my browser.

My next troubleshooting step was to dump network traffic with tcpdump on the hypervisor itself. I dumped the traffic on port 5900 (which was the VNC port for this particular instance) and watched the output. Whenever I wiggled the mouse over the noVNC console in my browser, I saw a flurry of network traffic. The same thing happened if I punched lots of keys on the keyboard. At this point, it was clear that the keyboard input was making it to the hypervisor, but it wasn’t being handled correctly.

Test the console

Next, I opened up virt-manager, connected to the hypervisor, and opened a connection to the instance. The keyboard input worked fine there. I opened up remmina and connected via plain old VNC. The keyboard input worked fine there, too!

Investigate in the virtual machine

The system journal in the virtual machine had some interesting output:

It seems like my keyboard input was being lost in translation — literally. I have a US layout keyboard (Thinkpad X1 Carbon) and the virtual machine was configured with the en-us keymap:

A thorough Googling session revealed that it is not recommended to set a keymap for virtual machines in libvirt in most situations. I set the nova_console_keymap variable in /etc/openstack_deploy/user_variables.yml to an empty string:

I redeployed the nova service using the OpenStack-Ansible playbooks:

Once that was done, I powered off the virtual machine and powered it back on. (This is needed to ensure that the libvirt changes go into effect for the virtual machine.)

Great success! The keyboard was working in the noVNC console once again!

Photo credit: Wikipedia