|
|
tags:
all,
apache,
apachecon,
apacheweek,
bryce,
cve,
fedora,
fudcon,
geocaching,
gps,
ha,
jabber,
metrics,
microsoft,
nashville,
north carolina,
oscon,
red hat summit,
security,
trips
|
|
|
mark :: blog :: fedora
After spending the last 3 years working every day on my trusty T41
laptop (dual screen with external TFT) I decided to build myself a new
desktop Linux PC so I could go to triple-head, play 3D games, use
vmware, and compiles wouldn't take so long. The components had to
work well with Linux and the goal was a low power, silent, PC. Here
is what I ended up with:
- Processor: Intel Core 2 Duo E6600. Every other machine I've built
in the past has used AMD; but the E6600 has a much lower power
consumption and good price/performance.
- Motherboard: Intel D975XBX2 "Bad Axe 2". Nice MB, unfortunately
lm_sensors doesn't support the chipset yet so no fan speed reporting,
and the integrated hda sound works but doesn't let you do a loopback
from line in to line out with current alsa drivers. Motherboard is
teamed with a Ninja Scythe CPU cooler, 2Gb of 6400 memory, and
two Spinpoint P120 250Gb drives.
- Case: Antec P180B. I've used this case before. It's expensive
but has a thermally separate wind tunnel for the HDD and PSU, making
it really quiet and really efficient at getting rid of heat. The case
has three 120mm fans, but I currently only need to have one on low. I
used a Seatec 80% efficiency P-12 550W PSU with it.
- Graphics: Two XFX 7600GS. I need to run 3 DVI monitors, and the
7600GS was the lowest power dual-DVI card available whilst still
having an acceptable 3D performance (it's not going to see much 3D
work). The cards are also passive cooled and need no extra power
connections (they're currently running around 48C each, perfectly
fine).
- Monitors: Three HP LP2065 20" TFT. I settled on the HP monitors
as they have S-IPS LCD panels, thin bezels, and most importantly dual
DVI inputs (so I can share all three monitors with a second machine
without an expensive DVI KVM). They were also pretty cheap, GBP260
each including 3 year on site warranty, so three of these cost me less
than two widescreen 24" screens and gave me more screen area.
Currently running at 4800x1200 combined resolution, although any OpenGL
windows are limited to 4096x1200.
- OS: Red Hat Enterprise Linux x86_64.
So far things are working out well; it makes less noise than my water
cooler, and when mostly idle (streaming radio, vpn, background tasks)
consumes just 100W. Running "openssl speed" on both cores can take it
up to 150W, but over the week it's average has been 110W. I think it
would look nicer with one of those three-monitor
mounts, but they're a little expensive to justify.
Update: Andy Burns sent me a mail about his Intel MB working with lm85 sensor (reminder, must get a nice blosxom comment module). A quick modprobe lm85 force=0,0x2e; service lm_sensors start later and I now get temperatures and fan speed reporting. Thanks Andy!
We're changing the package signing key we use for all new Red Hat products.
Since 1999, all RPM packages in Red Hat products have been gpg signed by the master key "Red Hat, Inc <security@redhat.com>" (keyid DB42A60E). I'll call this the legacy signing key for the rest of this
article. This signature is one of two security mechanisms we use to ensure that customers can trust the installation of packages and their updates. The other is that the update client, up2date, checks the SSL server signature when it connects to the Red Hat Network to ensure that it only talks to official Red Hat servers; so removing the possibility of a man-in-the-middle attack.
From 2007, all new products will be signed with a different master key, "Red Hat, Inc. (release key) <security@redhat.com>" (keyid 37017186). This includes Red Hat Enterprise Linux 5, and any other new products that use RPM packages. The exception to this rule is that any new layered products designed for older versions of Enterprise Linux will still use the legacy key: so for example, a new version of the Application Stack for Red Hat Enterprise Linux 4 will be signed with the legacy key.
The legacy key hasn't been compromised so why change keys? It's all to do with the way the keys are stored and managed internal to Red Hat. The legacy key is a software key and so the key material exists, protected by a passphrase, on a hard disk. When packages need to be signed one of the Red Hat authorised signers manually runs a signing command, this calls rpm --resign which asks for the passphrase then in turn calls out to GNUpg to do the actual signature creation. So the authorised signers not only had the ability to sign with the key, but they also have the ability to read the key material. In theory this means that a malicious internal signer could copy the key, take it away with them, and sign whatever and whenever they
wanted. Or, more likely, a clever intruder who gained access to our internal network could perhaps capture the key and passphrase, compromising the key. The risks mean we've had to be really careful who has signing privileges with the legacy key and how the key signing is handled.
The new key, in contrast, was created in a hardware cryptographic device which does not allow the unprotected key material to be exported. This means we can give authorised signers the ability to sign with the key, but no one can ever can get access to the key material itself. This is an important distinction. If for example a current authorised signer switches roles and is no longer responsible for package signing we can instantly revoke their rights and know that they no longer have the ability to sign any more packages with that key.
There was no off-the-shelf solution available for hardware-based RPM key management, so we developed one internally ourselves. We used nCipher
nShield hardware security modules (FIPS 140-2 validated) for the key protection along with custom patches I developed to interface RPM/GNUpg to the unit. At the same time we also introduced an extra layer of abstraction to the signing software, so we can authorize signers using their existing
internal kerberos credentials.
So, as a customer, you won't really notice any difference. For Red Hat Enterprise Linux 5 you'll find the public keys on our website as well as in the /etc/pki/rpm-gpg/ directory and you'll be prompted when updating or installing new packages for the first time to import that new public key.
This change basically makes it easier for us to protect our signing key and reduce the risk of it being compromised, therefore reducing the chances we'll need to change the key and involve customer effort in the future.
Late last year a reporter contacted me who was interested in the
various security features and innovations in Red Hat Enterprise Linux
and Fedora. She particularly wanted to know the dates when each first
made it into a shipping product. In the end the article was published
in a German magazine and was not publically available. It's a shame
to waste the work as I don't think this has ever all been collected
together into one place before, so here is the table. It's possible
I've missed one or two of the features, and I've not broken down the
big things like SELinux where we could talk about the number of
default policies in each release or the number of binaries compiled
PIE, but drop me a mail if you see any issues.
New: Updated version from 7th January 2008
|
|
