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

What I’m looking forward to at IBM Interconnect 2017

By 1 Comment

Mandalay Bay Las Vegas IBM Interconnect 2017IBM Interconnect 2017 is coming up next month in Las Vegas. Last year’s conference was a whirlwind of useful talks, inspiring hallway conversations, and great networking opportunities. I was exhausted by the week’s end, but it was totally worth it.

One of my favorite sessions from last year was Tanmay Bakshi’s keynote. It was truly inspiring to see someone so young take command of such a large stage and teach us all something. I can’t wait to hear another of his talks.

Open Technology Summit (OTS)

This year, I’m interested to see the talks at the Open Technology Summit. It’s essentially a group of lightning talks from industry experts on a variety of topics. This year’s agenda has talks on OpenStack, Cloud Foundry, Blockchain, and others. Although the event is three hours long, it feels a lot shorter than that since each talk is anywhere from 10-20 minutes long.

The OTS starts on Sunday afternoon, so be sure to arrive in Las Vegas early enough to attend.

Security

Information security is always an interesting topic and I have my eye on the following sessions:

IT Transformation

Open Source

I hope to see you there!

Photo credit: By Ronnie Macdonald from Chelmsford, United Kingdom (Mandalay Bay) [CC BY 2.0], via Wikimedia Commons

systemd-networkd on Ubuntu 16.04 LTS (Xenial)

By 2 Comments

My OpenStack cloud depends on Ubuntu, and the latest release of OpenStack-Ansible (what I use to deploy OpenStack) requires Ubuntu 16.04 at a minimum. I tried upgrading the servers in place from Ubuntu 14.04 to 16.04, but that didn’t work so well. Those servers wouldn’t boot and the only recourse was a re-install.

Once I finished re-installing them (and wrestling with several installer bugs in Ubuntu 16.04), it was time to set up networking. The traditional network configurations in /etc/network/interfaces are fine, but they weren’t working the same way they were in 14.04. The VLAN configuration syntax appears to be different now.

But wait — 16.04 has systemd 229! I can use systemd-networkd to configure the network in a way that is a lot more familiar to me. I’ve made posts about systemd-networkd before and the simplicity in the configurations.

I started with some simple configurations:

Here’s a summary of the configurations:

  • Physical network interface is enp3s0
  • VLAN 10 is trunked down from a switch to that interface
  • Bridge br-mgmt should be on VLAN 10 (only send/receive traffic tagged with VLAN 10)

Once that was done, I restarted systemd-networkd to put the change into effect:

Great! Let’s check our work:

So the bridge has no interfaces and it’s in a no-carrier status. Why? Let’s check the journal:

The Could not append VLANs: Operation not permitted error is puzzling. After some searching on Google, I found a thread from Lennart:

But Ubuntu 16.04 has systemd 229:

I haven’t found a solution for this quite yet. Keep an eye on this post and I’ll update it once I know more!

ICC color profile for Lenovo ThinkPad X1 Carbon 4th generation

By 3 Comments

My new ThinkPad arrived this week and it is working well! The Fedora 25 installation was easy and all of the hardware was recognized immediately.

However, there was a downside. The display looked washed out and had a strange tint. It seemed to be more pale than the previous ThinkPad. The default ICC profile in GNOME didn’t help much.

There’s a helpful review over at NotebookCheck that has a link to an ICC profile generated from a 4th generation ThinkPad X1 Carbon. This profile was marginally better than GNOME’s default, but it still looked a bit more washed out than what it should be.

I picked up a ColorMunki Display and went through a fast calibration in GNOME’s Color Manager. The low quality run finished in under 10 minutes and the improvement was definitely noticeable. Colors look much deeper and less washed out. The display looks very similar to the previous generation ThinkPad X1 Carbon.

Feel free to give my ICC profile a try on your 4th generation X1 and let me know what you think!

Display auditd messages with journalctl

By 4 Comments

All systems running systemd come with a powerful tool for reviewing the system journal: journalctl. It allows you to get a quick look at the system journal while also allowing you to heavily customize your view of the log.

I logged into a server recently that was having a problem and I found that the audit logs weren’t going into syslog. That’s no problem — they’re in the system journal. The system journal was filled with tons of other messages, so I decided to limit the output only to messages from the auditd unit:

This isn’t helpful. I’m seeing messages about the auditd daemon itself. I want the actual output from the audit rules.

Then I remembered: the kernel is the one that sends messages about audit rules to the system journal. Let’s just look at what’s coming from the kernel instead:

This is worse! Luckily, the system journal keeps a lot more data about what it receives than just the text of the log line. We can dig into that extra data with the verbose option:

After running that command, search for one of the audit log lines in the output:

One of the identifiers we can use is _TRANSPORT=audit. Let’s pass that to journalctl and see what we get:

Success! You can get live output of the audit logs by tailing the output:

For more details on journalctl, refer to the online documentation.

augenrules fails with “rule exists” when loading rules into auditd

By 2 Comments

When I came back from the holiday break, I found that the openstack-ansible-security role wasn’t passing tests any longer. The Ansible playbook stopped when augenrules ran to load the new audit rules. The error wasn’t terribly helpful:

A duplicated rule?

I’ve been working on lots of changes to implement the Red Hat Enterprise Linux 7 Security Technical Implementation Guide (STIG) and I assumed I put in the same rule twice with an errant copy and paste.

That wasn’t the case. I checked the input rule file in /etc/audit/rules.d/ and found that all of the rules were unique.

Is something missing?

The augenrules command works by taking files from /etc/audit/rules.d/ and joining them together into /etc/audit/audit.rules. Based on the output from augenrules, the rule file checks out fine and it determined that the existing rule doesn’t need to be updated. However, augenrules is still unable to load the new rules into auditd.

I decided to check the first several lines of /etc/audit/rules.d/ to see if line 5 had a problem:

Two things looked strange to me:

  • Line 5 is correct and it is unique
  • Why are lines 2 and 3 blank?

I checked another CentOS 7 server and found the following in lines 2 and 3:

The -D deletes all previously loaded rules and -b increases the buffer size for busy periods. My rules weren’t loading properly because the -D was missing! Those two lines normally come from /etc/audit/rules.d/audit.rules, but that default file was not present.

Here’s what was going wrong:

  • augenrules read rules from rules.d/
  • augenrules found that the rules in rules.d/ were already in the main audit.rules file and didn’t need to be updated
  • augenrules attempted to load the rules into auditd, but that failed
  • auditd was rejecting the rules because at least one of them (line 5) already existed in the running rule set

All of this happened because the -D wasn’t handled first before new rules were loaded.

Fixing it

I decided to add the -D line explicitly in my rules file within rules.d/ to catch those situations when the audit.rules default file is missing. The augenrules command ensures that the line appears at the top of the rules when they are loaded into auditd.