It’s been a while since anyone has really gone through the Fedora Security Guide. In the few places I’ve poked at I’ve found a massive build-up of… old stuff. I’m quite sure that many of those commands don’t do what is said here any longer.
There are ~50 files that need to be looked at to make sure that the information is current and actually tells people the proper thing to do to secure their Linux system. In support of this mission (that I hope to complete before the release of Fedora 21) I’ve created a wiki page that outlines the goals, explains how to help, and lists the pages that need to be audited and/or updated. I’d appreciate some assistance if only to have more eyes looking over the pages and making comments on the wiki about things that need to be fixed.
It’s good to get a team together, face-to-face, that usually only meets virtually via IRC on occasion. The Fedora Docs Project team recently had such an opportunity when they met in the Red Hat offices in Raleigh and Brno. Linked by a video teleconference, the two groups converged to discuss new work-flows for Publican 4, hacking on some guides, discussing management issues, and working to get the new Docs website built and configured. Here are some of the highlights of the event:
Work-flow update for Publican 4
The release of Fedora 20 also saw the release of Publican 4. Publican 4 isn’t quite backwards compatible with the Publican 2 we were using so an update to our work-flow was necessary. We’ve also made it to a point in our work where using the old web.git repo for publishing just isn’t working any longer. The new way of publishing involves using Koji to build our documents in RPMs and place them safely into a repository where they can be grabbed by our backend server and be published to the world. This change not only represents new commands but also a different mindset to publishing. The new procedures were documented and tested so we’ll be able to start utilizing these as soon as our backend server gets fixed.
Guides hacked upon
You know those guides that seem to languish? Yeah, I’ve got a few of those. I did spend some time working on a few guides that will hopefully go live for Fedora 20 or 21.
The Accessibility Guide has really taken a backseat in recent releases. I’m not sure much has changed for many users but it’s good to keep the document current for any new users that may require a little assistance in making their computer work for them. I was able to take a lot of stuff out of the guide, mostly GNOME packages that are no longer in Fedora and add a couple of packages I found for KDE. I’m hoping I can do a better review of what’s available in Fedora before Fedora 21 comes around.
Amateur Radio Guide
I finally got around to adding CQRLOG to the guide. I really love CQRLOG as a logging program so I’m happy to share some of that information with other amateur radio operators that come to Fedora looking for a FOSS solution for their radio activities. John made a few additions as well so I suspect the next release will have some added goodness that people should find helpful.
This is where I spent most of my time working. The style guide was moved from the wiki into the guide and other useful information was added as well.
This guide has never really seen the light of day. This is due to the fact that translations of this guide would be nearly useless as they wouldn’t be in any particular order. Publican 4 fixes this long-standing bug and so I, once again, have hope to publish this book.
Yeah, there’s always some hacking on the security guide when I’m around. This time there was some testing of the new Yubikey Neo and getting them to do tricks inside Fedora.
New backend server
Videos of the FAD
The Fedora Security Guide has had a very complicated background. The guide, itself, started out as a series of entries on the Moin Moin wiki. The original article explained how to setup LUKS for full-disk encryption. That article sparked additional articles discussing setting up encryption for both data-at-rest and data-in-motion. When development was eventually moved to DocBookXML Red Hat donated its security guide code to Fedora’s guide which filled in the subject matter well. That combined effort later went on to create the Fedora Security Guide and, downstream, the RHEL 6 Security Guide.
I’m very proud of the effort that went into the guide from both Fedora community members and Red Hat-related contributors. Lots of information is now available in the guide and I’ve heard from more than several people that they use it as a reference for answering questions, hardening their systems, and understanding concepts. Hearing this type of feedback is quite helpful and knowing that my contributions are helping others is what drives my work on this guide.
I’ve noticed, though, that it has become incredibly difficult to maintain all this content. Much of it is clearly scope-creep from the original plan for the document. With much talk about the Fedora 20 release being a rebuilding release I thought it might be a good time to redefine the scope and goals. Having a somewhat narrower scope should help keep the document on topic and make it a better guide overall.
With that I propose the following:
Scope – The Fedora Security Guide documents instructions for hardening installations of certain high-visibility services that are shipped with Fedora. Additionally, instructions and concepts for securing data-at-rest and data-in-motion will also be maintained as long as the solutions are shipped from within the Fedora repositories.
- Document hardening instructions for high-visibility services such as Apache (httpd), postgresql and MariaDB, OpenSSH, and bind.
- Document hardening instructions for the “average desktop user”.
- Document means of encrypting data-at-rest.
- Document means of encryption and authenticating data-in-motion.
This is just an idea and comments are welcome. I’ll start hacking and cutting soon, though.
I received a report that the Fedora Security Guide does not address GRUB2. Yep, it doesn’t. I’m hoping to update the text sooner than later and make it available to the masses. Just wanted to put the word out there that hardening instructions for GRUB2 are not in the guide, yet. That is all.
The other day I received a note on IRC asking for a change to the Fedora Security Guide. The change would be on the LUKS procedure, specifically the process for writing random bits to the hard drive before putting the encrypted partition on top.
Because my current schedule doesn’t allow for research I was hoping others could help me determine if scrub is a valid replacement for dd. Specifically if scrub is faster without hurting security.
I believe the command for scrub is:
scrub -f -S -p random -b 8M /dev/md0
which would replace the dd command:
dd if=/dev/urandom of=/dev/
Anyone have any comments?
Thanks to Zoglesby, we now have new instructions for using Yubikey with your computer running Fedora! We’ll be finalizing the text and it may make a late entry in the F14 version of the Fedora Security Guide (or an early entry to the F15 version). Stay tuned!
Sparks’ Fedora Project Journal by Eric H Christensen is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.