Red 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 tools
The 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
-n flag, noting any that fail. As Grubb put it on the mailing list, it is most likely to catch accidentally-broken scripts, but is still important.
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.
Adam 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 distributions
Most 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
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.
Comments (2 posted)
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
-- David Nalley
Let's re-use the Porche thing again.
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?
-- Jesse Keating
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
Comments (none posted)
The 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.
Full Story (comments: 37)
The 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.
Comments (none posted)
The third alpha of Ubuntu Oneiric Ocelot (11.10) is available for testing.
Edubuntu, Kubuntu, Mythbuntu, and Lubuntu are also available.
Full Story (comments: none)
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.
Comments (none posted)
Nominations 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
" The nomination period ends August 22.
Full Story (comments: none)
Newsletters and articles of interest
Comments (none posted)
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.
Comments (4 posted)
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.
Comments (none posted)
Robert Millan looks
at recent improvements
in Debian GNU/kFreeBSD and tests
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.
Comments (none posted)
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.
Comments (none posted)
Page editor: Rebecca Sobol
Next page: Development>>