Archive
You are currently browsing the cormander blog archives
for May, 2008.
By cormander
If you’ve ever wanted to automate an installation of CentOS, you’ve probably used kickstart. It’s a great tool. I’ve even gone as far as writing a program which gathers network information on a running linux server, forces it to reboot into kickstart and do a net install of CentOS. There isn’t much to this Jedi Trick.
But Scott Shinn takes it to a whole new level with the Atomic Offline OS Installer (AOOI). This lovely script places the .iso into swap space, reboots into kickstart and installs the machine. It doesn’t need a network connection while it’s installing, hense the “Offline Installer” name.
This is a glorified version of what I’ve put together in the past – and I think I’ll be using it instead from now on.
Oh, and if you’re running a windows machine, fear not; he as recently made a Windows Version of AOOI. It’s written in Visual Basic, and does the same thing as the normal AOOI – reboots the machine into CentOS kickstart, wipes the system, and installs.
Now that’s impressive.
By cormander
The other day my boss told us about a situation he was in with a crazy lady. It had made the news that night, and today showed up on digg: woman ramming car into truck
Watching the clip I don’t actually see him anywhere and they don’t mention his name, but he was there – and keeping the woman from getting into the truck she rammed into after she got out of her own car.
Things like this happen all the time – but they hardly ever happen to someone I know, so I thought I’d post it.
By cormander
Have you ever looked at the .spec file for a RHEL kernel RPM? I mean, *really* looked at it? Holy patches batman! As of this writing, the RHEL 5.2 kernel has about 1600 patches. For the longest time I was always just outright amazed (and annoyed) by all those patches.
Today I spent some time doing the tedious work of going through a large chunk of them to see what they really all do – sometimes the name of the patch just doesn’t give it justice. I was also looking for some elusive security issues that have been “hush hush”.
I have to say, Brad from grsecurity was right; there are plenty of things such as NULL pointer exceptions that have security ramifications in the linux kernel that aren’t publicly disclosed. They are buried deep in the commit logs of the kernel, and not labeled as a security issue. I found evidence of this looking through these patches. Everything like this that I’ve seen so far has been sent and accepted upstream – but damn – makes me want to keep tabs on all new patches to the RHEL kernels.
I figured out pretty fast into my research that about 120 of the patches went in cleanly into my 2.6.24.7 kernel sources, and none conflicted with the grsecurity patch. Most of them, it seems, are “ugly hacks” or vendor hardware fixes that haven’t gone upstream yet.
About 200 of the patches applied cleanly to the 2.6.24.7 sources with the -R switch – these seem to be patches that got sent upstream and went into the main kernel verbatim (and haven’t changed since). Pretty impressive to have that kind of influence on a moving target like the Linux kernel.
The rest of the patches (still over a thousand) are a messload of back-ports, RHEL-specific enhancements that didn’t go upstream, changes to device drivers that either went upstream and have been modified since or no longer apply (or have been re-implemented).
To me it looks like RedHat reviews every single commit to git in the upstream linux kernel to see if it applies to their own kernels, they have a suite of regression testing for each patch, and commit it if there are no problems. They also appear to write their own patches when they have a specific problem (or accept patches directly from the hardware vendor where the problem happens). This all sounds like a lot of work – but those 1600 patches in the RHEL kernel were made over a long period of time. If you really think about it, hire a few engineers to review the upstream commits daily, and that’s all it takes. Then you just send over the interesting patches to go through the weekly regression testing on the development, so-to-be production RHEL kernels.
My impression before this research has always been “how inconvient, all these patches” when I would try to apply a patch or two to the RHEL kernel sources. But putting things in perspective now – this is no different from the upstream kernel which uses git. It’s just a hell of a lot more obvious because all the patches make the kernel.spec file huge, and git easily hides them all after each subsequent release.
The moral of the story? Well there are a few:
1) Treat the kernel source + patches as a whole: don’t try to insert a patch before any of them, and don’t take out a patch unless you *really really* need to; and if that’s the case, you’re probably better off grabbing the latest upstream kernel source and starting from there.
2) Not all known security issues are flashed across the heavens via CVE or other vulnerability database – so use a vendor kernel if you don’t want to the inconvenience of staying up-to-date with the latest upstream vanilla kernel … all those recompiles and reboots.
3) Linux Vendors really do know what they are doing – and this is why they charge money for their support.
So, I’m not amazed by all the patches anymore; I’m impressed. Also I’m no longer annoyed by them (well, for the most part). Amazing how your perspective on things changes when you get a taste of the other side of the fence.
By cormander
Here is a table I put together containing links to the National Vulnerability Database about various Common Vulnerabilities and Exposures (CVE) issues in the 2.6 Linux kernel from 2.6.18 and above:
Linux CVE List
I had originally posted it in here, but decided to make a “page” out of it since it’s something that’ll get updated for a long time.
By cormander
I have locked the 2.6.24 kernel tree with grsecurity as “stable”, and created a new “testing” directory in my grsecurity rpm yum repo. The testing directory contains the latest patches for the 2.6.25 kernel tree.
In a few days I’ll manage to get around to also adding the corresponding gradm (and other) tools to the testing tree, since the latest patches to grsecurity are an actual later version of grsecurity (2.1.12) and don’t work with the stable (2.1.11) version.
Sorry about this taking over a week after the 2.6.25.4 release – I had a compiler issue with the kernel and only the other day realized that it was due to a brain-dead attempt of mine to merge the fedora core 9 config with grsecurity:
http://forums.grsecurity.net/viewtopic.php?f=3&t=1978
I must have been distracted or had a lapse of sanity when I did my first attempt, and didn’t bother to look very deep into the issue until this past weekend.
Enjoy.
By cormander
I’ve been poking around for a while now for ideas on how to manage system-wide default policies with the grsecurity RBAC system while still being able to use the learn utility. I came across this:
http://linuxcc.de/grtool/
Its advertised feature is exactly what I’m looking for. I plan on playing around with it probably this weekend. It’s good place to start as for converting the learning-config to a directory.d like policy structure.
Anyway, I was thinking about going in a direction of a ton of different “default” policies, all turned off by default. A tool I’ll be writing, probably named “grpol”, will use a separate configuration set full of booleans that’ll determine which policies it puts into grsecurity. Kind of like the approach here:
http://wiki.centos.org/TipsAndTricks/SelinuxBooleans
A sample conceptual command:
grpol --enable service_restart_httpd
This would allow the root user to use the “/sbin/service” command to restart the apache service. The –disable switch would remove the policy.
If a change is made to grsecurity policy, it reloads the RBAC system (if running), and running the tool will only work under an admin role (unless rbac is off).
The idea here is to get more people using the grsecurity RBAC system, because it’ll then be shipped with working default policies that are easily configurable, which is probably one of the reasons why SELinux is gaining momentum.
By cormander
Since last Friday I’ve been on call at work which means I have this blackberry phone glued to my hip that buzzes about every 5 minutes, annoying as hell. Thank goodness I only have to do this for one week, every six weeks or so. This is mainly the reason for me not posting anything in 5 days.
At least I get a nifty little wireless card for my laptop, and a very legitimate excuse to be on my computer all day (especially at home). I’ve been working on various things and hope to make visible updates to the rest of the world by the weekend.
On a side note, yesterday I sent off my first email to the “RedHat Security Response Team” about two CVE issues that didn’t appear anywhere in their bugzilla; the Fedora Core 8 kernel is affected. I was going to put it in bugzilla but then that email was listed for security issues. I got a reply this morning thanking me for the report, and saying that disclosure of vulnerabilities that have been already made public (like through the CVE system) can just be posted directly to bugzilla. Good to know the next time this happens.
I linked them to the two patches here:
http://www.ravencore.com/packages/kernel-grsec/
(BTW – those are in that kernel grsec source RPM)
They posted the two bugzilla tickets on this (they CC’d me, how nice of them):
https://bugzilla.redhat.com/show_bug.cgi?id=446031
https://bugzilla.redhat.com/show_bug.cgi?id=446060
I also sent these over to Brad at grsecurity…. lets see if he does anything about it.
By cormander
After using a .torrent file in my BitTorrent client to download FC9, it got me thinking. Now we all have issues with downloading things, OS package updates in particular. The climax of the thought came from trying to update my fc9 installation; only a few packages and the RPMs took FOREVER to download, probably because of overloaded fedora mirrors serving out the recently released FC9 and subsequent updates.
The idea for “YumTorrent” – a yum plugin to use the BitTorrent P2P communications protocol – is born. I’ve been looking for a reason to learn python for a while now, this just might be it. I had a look at the yum plugins guide:
http://wiki.linux.duke.edu/WritingYumPlugins
Seems perfectly reasonable to me. I’ll have to do some more research on this.
Basically YumTorrent would run as a daemon in the background, and work just like the BitTorrent client, serving requests to download given RPM files that exist in the yum cache. There is no need for a .torrent file, as the information can be assumed from the xmlrepo data (or directly from the sqlite database that yum uses). A trackerless system would be used (in other words, YumTorrent will maintain a list of every peer it’s ever used) and will consult them all for the existence of the desired file. If a particular peer hasn’t been accessible for a configured amount of time, they’re pruned from the list.
In addition to sharing files, YumTorrent peers could also share seed lists to further propogate a list of available download sites, since this is a trackerless system. If no suitable seeds are found, the plugin falls back to normal mirrorlist / baseurl to fetch the RPM files.
Since RPMs from mirrors are generally always the same name, we won’t run into any problems. Also, the issue of security with p2p clients isn’t of concern here either, since yum already does checksums from the repo file and GPG checks.
I’ll submit this project for approval on ShareSource and possibly SourceForge as well.
By cormander
I often download distributions just for a build environment, I don’t actually install it on the whole system. This makes testing basic packages among different flavors of linux very easy to do.
Since I mainly use these for building and running basic programs, I generally don’t want to have to add the extra overhead of using a virtual machine, so I put the entire OS inside of a chroot on my base OS.
In this example, I’m installing Fedora Core 9 into a chroot environment using the DVD iso I downlaoded, and the yum utility. The base OS I have here is CentOS 5, but it can be any OS that has yum installed.
These steps work to install pretty much any fedora distribution; in fact, anything these steps work for any distribution that is RPM based and uses “XML Repo” package headers, so it can be setup with yum. It works on CentOS, RHEL, and believe it or not, opensuse (the latest versions of the “yast” utility uses XML Repo).
Here we go:
# create target directories
mkdir -p /var/distro/Fedora-9/dev
mkdir -p /var/distro/Fedora-9/etc
mkdir -p /var/distro/Fedora-9/proc
mkdir -p /var/distro/Fedora-9/var/lib/rpm
mkdir -p /var/distro/Fedora-9/mnt/fc9-dvd
cp /etc/resolv.conf /var/distro/Fedora-9/etc/
# setup the installroot so yum works inside it
mknod /var/distro/Fedora-9/dev/null c 1 3
mount -t proc none /var/distro/Fedora-9/proc
rpm --root /var/distro/Fedora-9 --initdb
# mount your Fedora-9 DVD iso image
# NOTE: change /PATH/TO/ to the path to your .iso file
mount -o loop /PATH/TO/Fedora-9-i386-DVD.iso /var/distro/Fedora-9/mnt/fc9-dvd
# create a symlink to the target iso mount
ln -s /var/distro/Fedora-9/mnt/fc9-dvd /mnt/
# force the install of the release file so we can use its contents for yum
rpm --root /var/distro/Fedora-9 -Uvh --nodeps /var/distro/Fedora-9/mnt/fc9-dvd/Packages/fedora-release-9-2.noarch.rpm
# import the Fedora GPG key
rpm --root /var/distro/Fedora-9 --import http://download.fedora.redhat.com/pub/fedora/linux/releases/9/Fedora/i386/os/RPM-GPG-KEY-fedora
Now you need to edit the main repo file:
vi /var/distro/Fedora-9/etc/yum.repos.d/fedora.repo
Comment out the “mirrorlist” line, and under it add a new line:
baseurl=file:///mnt/fc9-dvd/
Also, edit the updates file and turn it off:
vi /var/distro/Fedora-9/etc/yum.repos.d/fedora-updates.repo
Change “enabled=1″ to “enabled=0″
Then proceed with the installation:
yum --installroot=/var/distro/Fedora-9 -y install wget bash gcc rpm-build \
make yum rootfiles pam pam-devel bzip2-devel curl-devel gmp-devel \
libjpeg-devel libpng-devel smtpdaemon ncurses-devel freetype-devel \
vim-minimal
You can add stuff or remove stuff from that list as needed. I added gcc, rpm-build, patch, make, and a few devel packages because I use this as a build environment. You’re welcome to change the “yum install” line as you see fit.
After you’re done, simply chroot into the base directory:
chroot /var/distro/Fedora-9
From in there, you can use the system as normal.
NOTE: if you want to install updates, be sure to re-enable the updates repo!
vi /etc/yum.repos.d/fedora-updates.repo
yum update
And that’s it, you’re done. Happy Fedora’ing.
By cormander
Today I put together my different patches to rootsh and uploaded it as a maintenance release to the rootsh project, which I have recently gained admin rights to since the previous admin has been inactive for 3 years.
I’ve also added the source RPM to my packages directory
You can read about the changes in the news release on sourceforge.
