[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Binary security updates
I've put together a basic binary updates tool aimed at people who want
to track a security branch without keeping a source tree and
recompiling. I have tested this code to the best of my ability -- but
since I only have one FreeBSD box (and it's on the other side of the
world), that ability is rather limited.
The modus operandi of this tool is simple: Build a -RELEASE world, build
world(s) along the security branch, and compare. Unfortunately the details
are a bit more complicated: Before comparing we have to strip out various
time/date/user/host stamps -- stamps which we locate by building the same
world twice.
An RSA key is generated and used to sign the updates for security
purposes. Once signed, however, the updates can be distributed via
insecure means (eg, HTTP).
At the client side, updates are fetched (and verified) into a staging
directory; they are then installed on command (preferably in single-user
mode, of course) and a rollback directory is created. In order for files
to be updated, their original MD5 hashes must be correct, so any local
modifications to the world will result in files not being updated.
A few more incidental notes, in no specific order:
1. The practice of bumping newvers.sh for security updates leads to
world-only updates causing the kernel to change. As a workaround, my code
replaces the kernel stamp with a generic -SECURITY stamp.
2. /usr/lib/libobjc.a (and _p.a) is wierd; it is the only file in the world
which builds completely differently every time. As a result, it gets
ignored -- any security updates here will not be propagated.
3. A few other files (.../perllocal.pod, ...doc/psd/*, ...doc/usd/*,
...phantasia/void) are obviously not security-related, but have some messy
variability; I'm ignoring those files as well.
4. I just realized that I'm snapping hard links if any such files need
updating. Oops.
5. Anything else which doesn't update properly if it has another file mv'ed
onto it won't be updated properly. I'm not sure if this applies to
anything except /boot stuff.
6. In order to locate the time and date stamps, I play games with the time;
the server code won't work properly if you have anything like ntp running.
7. The license is unusual. GPL fanatics will probably not be very happy.
8. This code should not be used to update anything other than a binary
install of -RELEASE: If you use it to update a world you have built
yourself, some files will not be updated (due to differing MD5 hashes).
Thanks to: Chad David and Terry Lambert for helping me understand the
build process; Nick Geyer and netwave.com for giving me some temporary
webspace while I work out where I'm going to put this permanently.
Now, for those of you who have read this far:
The server code is at http://cperciva.netwave.com/freebsd-update-server.tgz
with MD5 hash a9bbf3f514314b2e63ce54cc85246bd8
The client code is at http://cperciva.netwave.com/freebsd-update-client.tgz
with MD5 hash 35da1fb837edf4fb86979d728c24d719
The client code includes a configuration file which will fetch updates
(from 4.7-RELEASE to RELENG_4_7) which I have published -- I leave it up to
you to decide if you want to trust me.
Note that the above URLs are temporary; at some point I'll move these to
a more permanent home. For that reason, I'd suggest not linking to them.
Merry Christmas,
Colin Percival
To Unsubscribe: send mail to majordomo@xxxxxxxxxxx
with "unsubscribe freebsd-binup" in the body of the message