LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Announcements
->One big page
This page
Previous weekFollowing week
| |||||||||||||
DistributionsSecurity testing tools for FedoraRed Hat's Steve Grubb recently unveiled a suite of lightweight Linux security-testing tools. Grubb's tools are not a post-installation system audit; rather, they help the distribution team find and catalog common problems with binary packages, scripts, and applications. Although he announced them on a Fedora project mailing list, they are not inherently distribution-specific, so other distributions may want to look into them and adapt them for their needs. The security assessment toolsThe announcement came in an August 3 email to the Fedora testers' list. Grubb described the collection as "for assessing security of the distribution. It is by no means a comprehensive auditing tool, but the scripts definitely find problems." The collection, which is hosted at Grubb's personal Red Hat page, is introduced with:
Sometimes you want to check different aspects of a distribution for security problems. This can be anything from file permissions to correctness of code. This page is a collection of those tools. Depending on what information the tool has to access, it may need to be run as root.
The page currently hosts thirteen utilities, all of them shell scripts. The first script's comment block describes it as being available under GPLv2. Most of the others simply mention "the GNU public license," although a few extremely short scripts (of one to three lines each) do not mention licensing at all. The longer scripts are commented with the purpose and usage instructions, although Grubb also includes a plain English description of each script on the main page. The scripts are designed to iterate through the filesystem looking for specific security-setting, permissions, or behavioral problems that might not get caught by the normal QA process. Grubb said in his introductory email that he has found problems in Fedora 15 with all of the scripts. The first two on the page tackle compatibility with particular policies. The first, stig-file-test.sh, is the longest, and tests for compatibility with the US Defense Information Systems Agency's (DISA's) Security Technical Implementation Guide (STIG) for Unix systems. The STIGs contain "technical guidance to 'lock down' information systems/software that might otherwise be vulnerable to a malicious computer attack," including basic guidelines on things like file and directory ownership and permissions. The script incorporates 35 individual tests for log, library, configuration, system command files, and miscellaneous directories. Each test includes a comment that references a section of the most recent Unix STIG. The second script, rpm-chksec, tests for compatibility with Fedora's recommendations for ELF executables. It checks RPMs to see if the binaries it contains were compiled with the Position Independent Executables (PIE) and Relocation Read-Only (RELRO) compiler flags. It can either be run against a single RPM or against all packages installed on the target system. The next five scripts each deal with detecting an individual risk factor with executables. The find-nodrop-groups and rpm-nodrop-groups scripts look for programs (installed programs in the former script; RPM packages in the latter) that use setgid without using either initgroups or setgroups. Without such safeguards, the program inherits all of the groups of the calling user, and can thus unintentionally run with elevated privileges. The find-chroot and find-chroot-py scripts look for programs and Python scripts that call chroot but do not call chdir, and thus may have the current working directory outside the chroot sandbox. The find-execstack script looks for programs that have marked the stack as executable (which opens the door to an attacker using a stack buffer overflow to execute arbitrary code). The find-hidden-exec script looks for executables that are "hidden" — in the sense that either their name or the name of one of their parent directories begins with a ".". That is not intrinsically a security problem (particularly on a production machine, post-installation), but from the distribution's perspective it is highly suspect for a fresh install and warrants investigation. The find-sh4errors script simply attempts to parse all shell scripts with sh's There are two SELinux scripts, one that checks for devices in /dev that are incorrectly labeled, and one that checks the running processes to find daemons that do not have an SELinux policy. In both cases the results depend on the hardware and the daemons that happen to be in use on the test system, rather than reporting all possible problems in the distribution. Finally, there are two scripts to check the behavior of programs with regard to temporary file creation. One checks all shell scripts to look for any that are using /tmp as a temporary storage location but have not called the mktemp utility. The other checks binary executables to find programs that are using /tmp but do not appear to be using a good pseudo-random name generator to create file names. Both of these scripts are called works-in-progress that may generate false positives, but they are helpful nonetheless. A program that uses /tmp but employs predictable file names may be vulnerable to attacks that replace the real temporary file with a malicious payload. There are also problems with privileged programs that use predictable file names that could be symbolically linked to another file by an attacker. Fedora QAAdam Williamson of the Fedora QA team replied to Grubb's post asking whether or not the tests could be integrated into the distribution's AutoQA test framework, which watches for new package builds (among other events) and executes tests against them. Grubb cautioned that not all of the scripts were robust enough yet to be relied on in automated tests, but that most were good enough for the general QA process.
For example, the shell error test...why would anyone purposely write shell script that does not work? This can always be fixed before a release. Some tests are still under development like the ELF binary well known tmp file test. This can make some false positives, but there are enough good things in it to start asking real questions about packages...like.../home/cagney/tmp/a.out...why is that in any program?
AutoQA developer Kamil Paral expressed interest in adding the tests to the system, with a few changes. The scripts would need AutoQA wrappers to be written, in order to be managed by AutoQA's test "harnesses." The scripts would also need to be added to the AutoQA Git repository, as the infrastructure does not handle outside tests, and would need to be modified to report results via email to package maintainers, which is AutoQA's only notification method. As they are now, the scripts report the security faults they discover to stdout, most with color-coding to highlight the severity of problems found. "That said," Paral concluded, "we would love to execute more tests for Fedora. But until the proper support is ready, it takes quite some effort. The first approach is go through the tests, select some appropriate ones and do that now." An alternative suggested by Paral would be to wait until AutoQA could be adapted to handle third-party tests, but there was no time frame for that feature enhancement. In the meantime, Grubb asked Fedora testers to run the scripts manually, particularly the rpm-chksec script that looks for the recommended compiler flags. Fedora 16 has adopted a new policy with regard to RELRO, recommending that all packages be compiled with at least "partial" RELRO support, and important programs use RELRO in full. For other distributionsMost other distributions have started moving towards RELRO and PIE in recent years, and although SELinux is still not the default in several major distributions, the majority of Grubb's other scripts could prove to be useful QA tools on non-Fedora systems as well. The chief obstacle is that many of them rely on the rpm command-line tool to inspect packages (and not just those that look for RPM package problems). For example, the find-chroot and find-chroot-py scripts both use rpm to detect and then report which package owns any problematic file. When you execute it on a Debian-based system, it flags the packages but tacks on the semantically-valid-sounding (but incorrect) message "file FOO is not owned by any package." The same is true of find-sh4errors, find-execstack, and the /tmp usage scripts. Apt offers the same functionality, so adapting the rpm-dependent scripts to work in an Apt-based distribution would not be difficult. Still, the other scripts are useful today even on Debian-based systems. I ran several of them on my normal Ubuntu desktop machine, and was surprised to find (for example) how many hidden executables there were tucked away. The majority were not actually ELF binaries or scripts of any kind — although there were a handful of oddly-named PHP files from some packages I have tested — instead they were backup data files, such as OS X resource files of raw photos from the last time I traveled with an Apple laptop and a camera. They were named .IMG_NNNN and were of no value — but they definitely did not need the execute bit set. That example is still a good illustration of the value of Grubb's QA tools, however: the permissions were wrong, even if (as far as I could tell) the contents were not dangerous. From a security standpoint, finding seemingly-innocuous permissions or ownership problems is just as important for a distribution as verifying patches that fix known CVEs. Although no one would intentionally ship a broken shell script or choose a guessable temporary file name, their presence on the installer image still constitutes a risk to users.
Brief items Distribution quotes of the week
I go to my local Porsche dealer, and he has some nice cars, but they
really don't have the options I am looking for on the car I want on
the lot. (though they have plenty of the brand and model (analogous to
Distribution and version). Instead - the dealer offers to order from
the factory the Brand and Model of car that I want, with the factory
options that I want. They aren't going to give me a Yugo, Ford, or
Ferrari engine, that's not one of the options the factory (analogous
for the official repository of fedora packages) will deliver. And if
the dealer offered to rip the engine out, and put a Yugo engine in it
for me, I'd agree, it'd stop being a Porsche. It would be based on a
Porsche, but not truly a Porsche anymore. I think this is even more
apropos because there are factory approved and supplied options that
the dealer can install and still sell and call the vehicle by the
Brand.
-- David Nalley
Let's re-use the Porche thing again.
-- Jesse Keating
You can go to a Porche dealership and order what they have on the lot, or you can have them install genuine Porche accessories at the dealership, or at the factory. This is all well and good. Where this breaks down is if you buy a Porche, buy some genuine parts from the factory and install them yourself, and now try to sell the car as a genuine new Porche. It's a car, it has Porche parts on it, but was the install done right? Did all the guidelines and directions get followed correctly? This is more in line with Fedora creating a virt image and a 3rd party creating a virt image. The creation involves taking what we ship and $DOING_STUFF with it. That stuff can make a difference to the end user experience, and I think that's the concern here. Is the STUFF being done in an acceptable way to Fedora the project? Are we comfortable letting random folks DO_STUFF to our offering and still call it Fedora?
During said DebConf8, I had a dream (it was almost a nightmare, actually):
I woke up and just like that, I was the DPL. I spoke to some people about
this dream and to my complete surprise many said that I should actually do
it.
--Margarita Manterola
No Btrfs by default in Fedora 16The Fedora project has backed off of its goal to run on Btrfs by default in the F16 release. "Fesco outlined basic requirements that needed to be met by Alpha for the switch to be allowed to happen and we have not met those requirements so it won't be happening for F16." Among other things, those requirements include a working filesystem checker, and that is not yet on offer.
Gentoo Linux 11.2 LiveDVDThe Gentoo Linux 11.2 LiveDVD is available. "System packages include: Linux kernel 3.0 (with Gentoo patches), Accessibility Support with Speakup, Bash 4.2, GLIBC 2.13-r2, GCC 4.5.2, Binutils 2.21.1, Python 2.7.2 and 3.2, Perl 5.12.4, and more." There's a good selection of desktop environments and window managers along with plenty of new and updated packages throughout.
Ubuntu Oneiric Ocelot Alpha 3 ReleasedThe third alpha of Ubuntu Oneiric Ocelot (11.10) is available for testing. Edubuntu, Kubuntu, Mythbuntu, and Lubuntu are also available.
Distribution News openSUSE openSUSE Strategy done!The openSUSE project has been working on strategy document for nearly two years. The process has been completed. "Almost 2 years ago, at the first openSUSE conference, a discussion started about Strategy. A few months ago a final document was ready and on July 14th 2011, the strategy voting ended. Over 200 of the openSUSE Members voted, with 90% in favor of the document."
Ubuntu family Vacant Ubuntu Developer Membership Board seat: Call for nominationsNominations are open for a vacant seat on the Ubuntu Developer Membership Board. "The DMB is responsible for reviewing and approving new Ubuntu developers, meeting for about an hour once a fortnight. Candidates should be Ubuntu developers themselves, and should be well qualified to evaluate prospective Ubuntu developers and decide when to entrust them with developer privileges or to grant them Ubuntu membership status." The nomination period ends August 22.
Newsletters and articles of interest Distribution newsletters
Open Embedded: An alternative way to build embedded Linux distributions (EETimes)EETimes takes a look at the Open Embedded (OE) build environment. "In this article we present an overview of the key elements of the OE build environment and illustrate how these elements can be applied to build and customize Linux distributions. The Texas Instruments Arago distribution, which is based on the Angstrom distribution, will be used as example of how to create a new distribution based on OE and the distributions that already use it."
The Six Best Linux Community Server Distributions (Linux.com)Carla Schroder looks for the best community server distribution. "I have a soft spot for community-powered distros because they are labors of love, and provide a useful counterbalance to corporate follies. The two top Linux distros, Red Hat and Debian, represent opposite sides of the same Linux coin; Red Hat is a commercial success, while Debian will always be both libre software and free of cost. Both have been around since the early days of Linux, both have a commitment to free software, and they are the two fundamental distros that the majority of other distros are descended from. This shows that both models work, that both have their merits and are complementary."
Millan: Debian GNU/kFreeBSDRobert Millan looks at recent improvements in Debian GNU/kFreeBSD and tests it on his main workstation. From the second article: "During the last few weeks I had to work through some of the limitations that were holding me back, such automated driver load and FUSE. I was lucky enough that other people filled the missing pieces I wanted, such as NFS client support and a GRUB bugfix that broke booting from Mirrored pools. I have to say that I'm very satisfied."
The best Linux distro of 2011! (TuxRadar)TuxRadar takes Fedora, Mint, Arch, Ubuntu, Debian and openSUSE for a spin and grades them on ease of installation, hardware support, desktop, customization, community, performance, package management, cutting edge, and security. "Whilst no scientific stone has been left unsubjected to a transformation matrix, bear in mind that their isn't any science known to man or penguin that can accurately quantify a lot of the qualities we look for in a version of Linux. A lot of it will be completely subjective, depending on the wants and needs of the individual user. For one thing, when we totted up the medal table to produce the result, we were assuming that all categories were equal. This is very unlikely to be the case, to be honest - if it was, everyone would be using the same distro."
Page editor: Rebecca Sobol |
|||||||||||||