By default, and for nearly a decade now, prelink has shipped with Red Hat Enterprise Linux and Fedora. What it does is modify the ELF code in binaries and libraries to speed up load times, so that fewer relocations need to be resolved when executing a program. I can’t explain all the details and technicalities of it because, quite frankly, they are above my limited brainpower to explain. Suffice it to say, prelinking is a good thing. Unless you are using AIDE or Tripwire. These programs determine whether or not a file has changed based on their MD5SUM or SHA1SUM (or any other *SUM of the binary). So when you install a program, AIDE sees a certain MD5SUM of the binary. Later, when prelink runs, that binary might be modified to do the aforementioned relocations. This will result in a different MD5SUM of the binary, and AIDE will most certainly tell you about the change. What does not inform you of the change, however, is rpm -V (or rpm –verify).

The verification command in RPM tells it to compare the MD5SUM of the files in certain package to what is on the filesystem. It’s a poor man’s AIDE, and can also tell you what has changed on your system (from what RPM expects according to when it was installed). In theory, you would expect rpm -V to report the same discrepancy that AIDE does. The fact that it doesn’t is what’s led to a few questions regarding this.

The “problem” (if you can call it that) is that rpm knows about prelink, and knows how to deal with it. As is succinctly explained in this mailing list email, “rpm when –verify will prelink –verify, which is essentially –undo followed by prelinking again and comparing.” So the reason that rpm doesn’t fail the verification is that it is basically turning off prelink for the file(s) to check, running the verification, then turning prelink back on. This is why rpm won’t report on a MD5SUM change, but AIDE will.

So for those of us who use AIDE, we know that we need to do things like daily runs to make sure nothing has changed. The problem is that if you do this and run a yum update, X number of hours later you’ll get an email telling you that files have changed. You might, at that point, update AIDE but there is a window of opportunity there where you may miss things. We can minimize this by doing an AIDE check, then yum update, then force a prelink run, then update AIDE. I’ve been doing this for a few years on Red Hat Enterprise Linux 5 and it essentially gets rid of all false positives. It’s a little script called do-update that I execute as root and it runs this:

#!/bin/sh
aidecheck && yum update -y && /etc/cron.daily/prelink && aideupdate

This doesn’t eliminate the window of opportunity completely, but it does lessen it considerably. This uses my AIDE_gpg scripts (aidecheck and aideupdate). The rest is pretty self-explanatory.

Hopefully this information will be useful to someone. It took me a bit to dig up the mailing list message I link to above; I knew that prelink was had some special relationship with rpm, but I didn’t know the particulars. Now I do, and so do you. =)

The first is to setup some global options, some of which are nice for folks coming from Subversion. Having a global ignore file is useful. Mine has the following contents:

*~
*.orig
*.rej
*.swp
.#*
*.o
.DS_Store

Then adjust some global git options:

$ git config --global core.excludesfile ~/.gitignore
$ git config --global alias.st status
$ git config --global alias.ci commit
$ git config --global alias.co checkout
$ git config --global alias.br branch
$ git config --global user.name "Your Name"
$ git config --global user.email you@example.com
$ git config --global core.editor "vim"
$ git config --global color.branch auto
$ git config --global color.diff auto
$ git config --global color.interactive auto
$ git config --global color.status auto

The last few allow for colorized output, which I like (makes things like git status easier to read).

I also found out that I had screwed up the remote origin when setting up a new repository, and didn’t want to re-do everything, so found this useful one-liner:

$ git remote rm origin

Git n00bs like me will appreciate the above. =) (Note to self, express git urls as ssh://git.remote.com/path/to/repo.git rather than ssh://git.remote.com:/path/to/repo.git!)

Finally, I found an excellent resource called Create a new Git Remote Repository from some local files (or local git repository). Very accurate, very clear, and very easy to follow. Essentially I was taking a 4GB set of documents and wanted to turn it into a remote repository so that I could push/pull from my laptop and using this article, I was able to do so easily.

I think, honestly, the biggest pain in the arse was making Apache’s rewrite rules work the way I wanted them to. I still have the annvix.org domain, and moving the subversion viewvc and repo sub-domain is silly and painful (and neither require much effort on my part), so I’ve left them but still wanted to redirect http://annvix.org/foo to http://linsec.ca/Annvix:foo. Easy enough without cPanel getting in the way and .htaccess files and whatnot, so I finally got it working after much goatee tugging. For the interested, the pertinent bits of the .htaccess file I ended up using are below (criticism welcome!)

Options All -Indexes FollowSymLinks

RedirectMatch permanent ^/repo/$ http://repo.annvix.org/

RedirectMatch permanent ^Annvix:(.+)$ http://linsec.ca/Annvix:$1

RewriteEngine on

RewriteCond %{HTTP_HOST} !^repo\.annvix\.org [NC]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.+)$ http://linsec.ca/Annvix:$1 [L,QSA]

The Apache mod_rewrite stuff always messes me up, so I’m sure there are prettier ways to do it, but at least this seems to work in all the cases that I want.

I’ve pulled out AIDE+gpg and rsec from the Annvix tools subversion repository and they are now on github:

AIDE+gpg on github
rsec on github

The next step, maybe for around Christmas, is to turn these into Fedora and/or EPEL packages so that I can (finally?) actually be a Fedora contributor beyond just filing security bugs. I may be the only one made happy by that, but I think it would be cool. =)

First, the location of AIDE+gpg in the subversion repo was “tools/AIDE+gpg” and it had one sub-directory, “trunk”. I never did end up using tags or branches or anything there. So the entire step from start to finish to do it was as follows:

git init AIDE
cd AIDE
echo "vdanen = Vincent Danen <[my email]>" >authors.txt
git svn init -T trunk svn+ssh://[repo]/tools/AIDE+gpg --no-metadata
git svn fetch -A authors.txt
git init --bare ../tmp
cd ../tmp
git symbolic-ref HEAD refs/heads/trunk
cd ../AIDE
git remote add bare ../tmp
git config remote.bare.push 'refs/remotes/*:refs/heads/*'
git push bare
cd ../tmp
git branch -a
git branch -m trunk master
mv tmp AIDE+gpg.git

Presto. Done. Apparently I should now put this repo somewhere public (like github). I will figure that part out after lunch.

The problem is that all of my version control repos are in subversion, and I hate losing history. On some, I went through a painful CVS->SVN migration when I first started using subversion, and I was pleasantly surprised that git makes it quite a bit easier. I found this blog posting that helped me (for the most part… if you don’t use tags and branches, etc. you want to pay attention when doing some of the steps… took me a bit to figure that out). Most notably, in steps four and five when changing the “trunk” to “master”; it assumes you have the standard trunk/, tags/, branches/ layout (which I do in some repos, and not in others). If you use that convention, it works fine. If not, you can run into problems like I did.

The posting indicates to use:

git svn clone [SVN repo URL] --no-metadata -A authors-transform.txt \
   --stdlayout ~/temp
...
git init --bare ~/new-bare.git
cd ~/new-bare.git
git symbolic-ref HEAD refs/heads/trunk
cd ~/temp
git remote add bare ~/new-bare.git
git config remote.bare.push 'refs/remotes/*:refs/heads/*'
git push bare
cd ~/new-bare.git
git branch -m trunk master

But this didn’t work for me, as –stdlayout isn’t so standard in my case (no tags/trunk/branches, so the top-level is the “trunk”). Instead I had to do:

git svn clone [svn repo] -A authors-transform.txt ~/tmp/git
cd ~/tmp/git
git init --bare ~/git/scripts.git
git remote add bare ~/git/scripts.git
git config remote.bare.push 'refs/remotes/*:refs/heads/*'
git push bare
cd ~/git/scripts.git
git branch -m git-svn master

In this case, the only branch is the “git-svn” branch, so we want to turn “git-svn” into “master” (rather than trying to hunt down some non-existant branch called “trunk”). There might have been a better way to do this, but I’m a n00b so forgive me. All the explanation for the above is in that blog post I mentioned before (I’m mostly noting this as undoubtably I’ll bump my head against this again).

Some other useful links I found were this git guide and a piece on setting up gitweb on Fedora (works on RHEL also). Gitweb was essential, as I’m used to using viewvc with my subversion repos.

So will I use git for all my repos? Probably not. There are some old ones that don’t need to be converted because it’s all legacy code, and there are some others that I’ve built up with too much automation. I would like to try to extract some pieces of existing subversion repos into git, however. The AIDE+gpg scripts are one; they’re in the Annvix tools repo, and I’d like to try to break it out into it’s own git repo with history… not sure if this is possible but I’ll poke around and see what I can come up with. There are a few other Annvix tools that I’d do the same with (the rsec tool for one). Since Annvix isn’t in development anymore, I’d like to “untie” those tools from it and offer them as stand-alone things (probably on github or something).

So that’s my Saturday adventures for this weekend. =)

Apparently someone other than myself uses these scripts. =) AIDE+gpg is a set of scripts to make AIDE more like Tripwire in that the database is cryptographically signed (with gpg) so you can be alerted as to whether or not the AIDE database has been tampered with between runs. It also setups a cron job to check the database against the system daily to alert you of any changes. It is an add-on to AIDE that can be used on any Linux distribution (and probably distributions as well, although you may need to edit the scripts if the binary locations for gpg and aide differ from RHEL).

You can grab it from the project page.

The only gotchya is that due to the replacement of init by systemd, when it came time to reboot, halt/reboot/etc were unable to send the correct signals to something that would shut the machine down, so I had to do a hard reboot (which never plays nice with my RAID arrays, but upon reboot there was no RAID re-sync which is either cool or scary, I’m not yet sure which). So that was a bit nerve-wracking. Otherwise it was just a lengthy process with yum telling me I had 2850 packages to deal with (including installing and removing). Instructions are good and clear. Highly recommended if you’re even moderately technically inclined.

Now I get a good look at GNOME3, which doesn’t work in my Fedora 15 vm’s (well, it works, but it looks a lot like GNOME2 due to the “poor” video support in a vm). I’m not sure what the big deal is… it’s a little wonky and takes some getting used to. I dislike that conky doesn’t show up on the desktop, but so far that’s my only real complaint. I had icons for Komodo and CrashPlan on the desktop that are no longer visible, so had to use alacarte (“yum install alacarte; alacarte”) to create new icons to go into the GNOME menu system. Then I could add them to my favourites and was off and running. It was about 1am when I finished so I haven’t had too much time to play with it yet (although I also installed LXDE to give it a go as well, in case I didn’t like GNOME3). So far I don’t mind it though.

Everything else seemed to work out of the box other than my apache configuration file. I have a few includes in /etc/httpd/conf/vhosts.d/*.conf and they weren’t loading, so I think the handling of virtual hosts has changed because once I removed the default virtualhost definition (““) that I had defined, the virtual hosts worked again.

All in all, I’m pleased. I’ve played with F15 in my vm’s since it came out (but mostly for testing security issues, etc.) so this is the first workstation with “stuff” that I’ve upgraded. So one work vm and one laptop to go and then F14 is history. Good job on this release, Fedora Folks!

This is also one of the last TechMails that TechRepublic will be publishing that I’ve written. There might be one or two more in the queue yet, I can’t remember if everything I’ve submitted has been published or not. It has been almost 12 years of writing monthly for TechRepublic — initially as full length articles and the last few years as blog-style tips (which are both easier and harder to write; you get less words and more topics to cover in a month). The last year or so I’ve also been writing Mac tips for TechRepublic, as one of the original contributors to the Mac track.

Twelve years is a long time, so it is with mixed feelings that I gave my resignation to TechRepublic last month. I’ve worked with some really great editors: Jack, Sonja, Selena… you guys have been great to work with and I will definitely miss working with you. I think, after a respite from technical writing, that I’ll work on updating some of the documentation I have on the linsec.ca wiki, and hopefully finish off a few more that I’ve started but never completed. At least writing for my own wiki there are no deadlines, no wracking the brain for various topics that appeal to a larger crowd (I can concentrate on the niche security/sysadmin stuff that I enjoy), so it should be a little more relaxed and hobby-ish, rather than feeling like “real work”.