The Fedora Security Team (FST) has uncovered an interesting problem. Many packages in Fedora aren’t being actively maintained meaning they are unofficially orphaned. This is likely not a problem since at least some of these packages will happily sit there and be well behaved. The ones we worry about are the ones that pick up CVEs along the way, warning of unscrupulous behaviour.
The FST has been plugging away at trying to help maintainers update their packages when security flaws are known to exist. So far we’ve almost hit the 250 bug level. Unfortunately we forced a policy that still isn’t perfect. What do you do with a package that is no longer is supported and has a known vulnerability in it? Unless you can recruit someone to adopt the package the only responsible choice you have is to retire the package and remove it from the repositories.
This, of course, leads to other problems, specifically that someone has that package installed and they know not that the package is no longer supported nor do they know it contains a security vulnerability. This morning, during the FST meeting, we discussed the problem a bit and I had an idea that I’ll share here in hopes of starting a discussion.
Create a file containing all the packages that have been retired from a repository and perhaps a short reason for why this package has been retired. Then have yum/dnf consume this information regularly and notify the user/admin when a package that is installed is added to this list. This allows the system admin to become aware of the unsupported nature of the package and allows them to make a decision as to whether or not to keep the package on the system.
Wow, I had no idea that people would care about the start of this project. There seems to be a few questions out there that I’d like to address here to clarify what we are doing and why.
OMG! Fedora is just getting a security team? Does this mean Fedora has been insecure this entire time?!?
Umm, no, it doesn’t mean that Fedora has been insecure this entire time. In all actuality Fedora is in pretty good shape overall. There is always room for improvement and so we’re organizing a team to help facilitate that improvement.
What exactly is the security team responsible for?
We here to help packagers get the patches or new releases that fix vulnerabilities into the Fedora repositories faster. Most of our packagers are very good at shipping fixes for bugs when upstream rolls a new version of their software. Bug fixes can usually wait a few days, though, as most aren’t critical. Security vulnerabilities are a bit different and fixes should be made available as soon as possible. A little helping hand is never a bad thing and that’s what we’re here to do… help.
Can the security team audit package x?
No. This may become a service a different team (also falling under the Security SIG) can provide but I/we haven’t gotten there yet.
I read where Fedora has 566 vulnerabilities! How can you say that Fedora isn’t insecure?
Well, it’s actually 573 right this second. That’s down from 577 last week. 566 was Monday’s number. It’s important to not get caught up in the numbers cause they are, well, just numbers. The numbers only deal specifically with the number of tickets open. Many of the tickets are duplicates in that the same vulnerability might have several tickets opened for it if the finding is in only certain Fedora versions and EPEL versions. Since the same packager is likely responsible for all versions and the same fix can be made we can likely close several bugs at a time with minimal work.
I should also point out that the majority of these bugs fall well below the “world is on fire” level of Critical and the “this isn’t good” level of Important. This doesn’t mean we should just ignore these lower vulnerabilities but rather we should understand that they aren’t something that is likely to be exploited without many other bad things happening. Should they be fixed? Yes, but we should probably be more concerned with the Critical and Important vulnerabilities first. If you’d like to know more about the process for coming up with the severity rating my friend Vincent wrote an excellent article that you should read.
“6. Close bug when vulnerability is shipped in Fedora repos.”
Yeah, that isn’t correct. This is what happens when I try to multi-task. Glad I don’t get paid to write…. err… never mind. Luckily it’s a wiki and someone fixed it for me. Whew!
(We try to not deliberately release a package with a vulnerability. It seems people don’t appreciate vulnerabilities in the same way they like other features. Who would have thought?)
I’d like to help! How can I join up?
Go to the Security Team wiki page and look for the link to the mailing list and IRC channels, sign up, join up, and use the work flow to start digging in. Questions? Feel free to ask in the IRC channel or on the mailing list. You can also contact me directly if can’t otherwise find the answer to your question.
Do you hate security vulnerabilities?
Do you want to help make Fedora more secure?
Do you have a little extra time in your week to do a little work (no coding required)?
If you answered yes to the questions above I want you for a beta test of an idea I have to help make Fedora more secure. I’m looking for just a few people (maybe five) to sort through security bugs and work with upstream and packagers to get patches or new releases into Fedora and help make everyone’s computing experience a little safer. If you’re interested please contact me (firstname.lastname@example.org 0x024BB3D1) and let me know you’re interested.
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.
After years of using caff for my PGP key-signing needs I finally come across the answer to a question I’ve had since the beginning. I document it here so that I may keep my sanity next time I go searching for the information.
My question was “how do you make a specific certification in a signature?”. As defined in RFC 1991, section 6.2.1, the four types of certifications are:
<10> - public key packet and user ID packet, generic certification ("I think this key was created by this user, but I won't say how sure I am") <11> - public key packet and user ID packet, persona certification ("This key was created by someone who has told me that he is this user") (#) <12> - public key packet and user ID packet, casual certification ("This key was created by someone who I believe, after casual verification, to be this user") (#) <13> - public key packet and user ID packet, positive certification ("This key was created by someone who I believe, after heavy-duty identification such as picture ID, to be this user") (#)
Generally speaking, the default settings in caff only provide the first level “generic” certification. Tonight I found information specific to ~/.caff/gnupghome/gpg.conf. This file can contain, as far as I know, can contain three lines:
ask-cert-level <- works in lieu of the default-cert-level to ask you on each signature
I can’t find any official information on this file as the man pages are a little slim on details. That said, if you use caff you should definitely create this file and populate it with the above at a minimum with the exception of the default-cert-level. The default-cert-level should be whatever you feel comfortable setting this as. My default is “2” for key signing parties (after I’ve inspected an “official” identification card and/or passport). The other two settings are important as they provide assurances of using a decent SHA-2 hash instead of the default
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.