Monthly Archives: July 2014

All of this should apply to all T440s models but I have specifically tested it on a model with Samsung SSD and Intel 7260 dual band wifi.

Scary options in BIOS

All these remote management, anti-theft and device location options really just fuel my paranoia. Turned them all off. I try to setup all my machines to be disposable, device recovery is very unlikely anyway.

Good options in BIOS

You can nicely lock it down with a supervisor password and disallow booting from any device other than the internal SSD. There is an option to disallow firmware flashing. Getting the laptop apart to wipe the settings is quite a pain so I think this does help a bit.

UEFI boot and GPT

Before installing Fedora, go to the BIOS/UEFI setup menu and switch to the Startup tab. Look for “UEFI/Legacy boot” and set it to “UEFI only”. I have also disabled CSM but I don’t think it affects anything with Fedora 20.

I couldn’t get the local pxeboot running with UEFI so I had to resort to a USB flash drive. Had no problems getting the machine to boot the USB drive. Fedora 20 x86_64 install ISO was used mainly because I already had it downloaded from before.

Pay close attention to partitioning in Anaconda. If you want TRIM/discard select Standard Partitioning. Don’t worry about having to type your password multiple times for multiple encrypted standard partitions. Anaconda will do what you want by default – a single password opens all your encrypted partitions.

Despite everyone raging on the internet about SSD alignment it seems very unlikely that partitioning tools would do a bad job by default. In my case the internal Samsung SSD exported its geometry correctly and Anaconda had done proper partition alignment. You can check this using parted:

sudo parted /dev/sda
# interactive interface of parted follows
align-check opt
# now you can cycle through all the partitions
# all are aligned in my case

The rest of the installation process is a breeze, everything seems to work out of the box.

Is UEFI worth the hassle? Probably not, I was mainly curious. The boot seems a bit faster but I have no solid data.

TRIM/discard and HDD encryption

TRIM may help with SSD performance. It’s probably overkill and very overrated but for the sake of learning about it I opted to set it up. Be advised that enabling it may leak structure information about how you use your drives – especially how much free space you got. See http://asalor.blogspot.cz/2011/08/trim-dm-crypt-problems.html for more details. Now that all the disclaimers are done, let us set up discard for encrypted drives.

The actual process was very simple, first you need to tell cryptsetup to allow discard to be enabled. Open /etc/crypttab and add “luks,discard” to each drive that is relevant. The end result should look like this:

luks-................... UUID=................... none luks,discard

I am not entirely sure if adding luks is necessary here but I do it anyway. The “luks” option forces LUKS mode. Now you can enable the discard option in /etc/fstab, add “discard” to the list of options in the relevant mount points. The end result should look something like this:

To make these changes effective on next boot you have to regenerate initramfs.

mount /boot
dracut --force

Testing with fstrim:

sudo fstrim /
sudo fstrim /home

Getting the function keys to work

If you use a big bulky desktop environment like KDE or Gnome this may already work out of the box. I use i3wm so I have to set it up manually.

Install the necessary dependencies:

sudo yum install xbacklight pulseaudio-utils

This is what I put into my i3config, should be easy to adapt for other window managers. It’s a bit messy and I may improve it later but it gets the job done for now. It has basic support for volume up, volume down, mute toggle, brightness up and brightness down.

Creating the file will automatically enable the rc-local.service unit in systemd. There is no need to enable it manually. You can verify this by running:

systemctl show rc-local.service

You can get amazing battery life out of this machine. 15+ hours is not a problem with moderate usage (with internal and 6 cell battery).

The LCD panel woes

The Full HD IPS T440s ship with 2 different LCD panels – AUO and LG. You can look up which one you got by grepping /var/log/Xorg.0.log. If it contains LP140WF1 you got what everyone considers the worse display – the LG. B140HAN01.2 is the AUO. You can read a lot of endless first world problem style whining about this here.

Outstanding issues

DisplayPort MST

As a workaround you can use the mini DisplayPort on the laptop itself even when the laptop is docked. The VGA port on the laptop unfortunately cannot be used. From what I can tell it is disabled when you put the laptop into the dockstation. Makes sense but why isn’t the miniDP disabled?

dockstation audio jack

Use the laptop combo audio port as a workaround. Works even when docked.

Fingerprint reader

… but who cares?

If bluetooth doesn’t work and the device doesn’t show up in `lsusb` it could be because you disabled the Fingerprint reader. Enable it to get bluetooth back. This issue could be specific to my firmware version 2.27.

TODO

Toggle all radio off with the wifi function key – just binding the key to nmcli radio all off works but doesn’t toggle

report fail and error rules by severity in addition to the standard XCCDF score system – TODO

sort by severity in rule overview – TODO

sort by identifiers in rule overview – TODO

false positive waiving, other means to pass feedback about why rule fails – probably out of scope, would need a new file format to store the waivers

xslt-devel branch

I have created a new branch in the openscap repository where I am continuing with this effort. Instead of a prototype HTML the repo has working XSLTs. Keep in mind that the branch breaks openscap tests and you can’t generate HTML report using the oscap tool command line. Instead you have to use xsltproc directly for now.

Screenshots

A mild change in color scheme, nothing you see here is set in stone thoughRule overview is not a hierarchy, shows groups and counts failed rules in each groupWhen you click on a rule a modal dialog with more details is shown, you no longer need to jump around the documentYou can hide all the failing rules to feel happier!Tree nodes in rule overview can be collapsed and expanded by clicking on themSimple keyword searching is implemented for XCCDF rules

Generated sample

All the usual disclaimers apply. This is not the final version, a lot more than is necessary is bundled, not everything works.

More feedback?

We have received many requests to change our HTML report in some way. In this post I will try to summarize what it is people want to change and try to come up with a proposal for our new HTML report.

I started with the HTML report but the plan is to update both report and guide generators. They share a lot of code even today, it makes sense to update them both.

Problems with the current approach

openscap uses docbook as an intermediary format. This means that when generating guides or reports, the XCCDF is transformed into docbook using XSLT, that docbook is then transformed into XHTML. This causes several problems.

XCCDF allows XHTML in description, front-matter, rear-matter and others. We have to convert XHTML to pseudo-docbook and then back to XHTML. Data is inevitably lost during this transformation because docbook cannot possibly support all of XHTML.

Furthermore, the maintenance costs of such an arrangement are enormous. The XSLTs are big and hard to navigate through.

I believe benefits gained from using docbook are very small if there are any at all. There are serious issues when trying to generate PDF from our docbook guide/report which leads me to believe that nobody is using alternative output formats.

Current openscap HTML report

Requested features

Our users have requested several features and changes. I tried to gather some of them and list them here. If you have other suggestions please leave a comment!

Rule filtering – for example to hide all passed rules

Rule sorting – for example by severity, to form a remediation priority queue

Design proposal

In my opinion we should base the new HTML guide and report on HTML5 and either Pattern Fly or Bootstrap, the project it’s based on. This should give us a starting point for visuals and usability. The new XSLT will no longer generate any docbook. Users that want PDF reports can generate them from the resulting HTML5.

The main problem with this is that we have to either bundle a lot of JavaScript and CSS, or fetch them from some remote site. From my estimates we would have to bundle ~200 kB with each guide and report. That seems quite excessive. I will try to bring the number down.

If that effort fails a reasonable compromise might be to bundle CSS and fetch JavaScript remotely if available. This means that open-scap.org would have to reliably host JavaScript resources for reports and guides. These would have to be frozen and versioned with diligence. Please note that even if the browser fails to load the JavaScript the basic functionality would still be available.

Prototype 1

What follows is a preliminary prototype. Not all planned functionality has been implemented.

I have used jQuery dataTables for search and sorting functionality. It supports pagination but I am unsure whether we want to use that or not.

Screenshots for the impatient:

Top of the HTML report prototypeExample of a failed rule “panel”Example of a passed rule “panel”

Plans

I would like to get some feedback from the community before I continue with this research. If the feedback is positive I plan to start an experimental branch in the openscap upstream repository with the actual XSLTs.

I can make no promises but the ambitious plan is to have a new HTML report and guide in openscap 1.1.0.