Security


Signing RPMs is supposed to be easy:

gpg --list-keys
cat > ~/.rpmmacros < <EOL
%_topdir /home/rob/rpmbuild
%debug_package %{nil}
%_signature gpg
%_gpg_name Rob A <me@totalnetsolutions.net>
%{__gpg} \
gpg --digest-algo=sha1 --batch --no-verbose --no-armor \
--force-v3-sigs --passphrase-fd 3 --no-secmem-warning -u "%{_gpg_name}" \
-sbo %{__signature_filename} %{__plaintext_filename}
EOL
rpm --resign

But there are a lot of caveats:

  1. If you run this on RHEL or CentOS or Scientific Linux 6.x and have an RSA, rather than a DSA, GPG key, any older systems (5.x or 4.x) won’t be able to properly decode the signatures. If you have a DSA key (and only v6+), the --force-v3-sigs is enough.
  2. If you run this on RHEL or CentOS 5.x, you need to remove the “–force-v3-sigs” option from the .rpmmacros line
  3. http://technosorcery.net/blog/2010/10/10/pitfalls-with-rpm-and-gpg/ is a bit wrong – RSA keys don’t always work, DSA do (there’s apparently a RHN KB article about this, if you have support and licenses to read it. I don’t right now).
  4. RHEL / CentOS / Scientific Linux 7 won’t accept (without warning) RPMs signed with weak keys (or weak digests, in some cases, like sha1)

So, based on the systems you’re trying to build your package for, ensure the signing key you’re using and the digest algorithm you’re using, are supported across all the versions you expect to support… or build multiple RPMs, and put them in separate repos for each OS version.

We ran into this bit of fun while setting up a NIS domain for testing in the lab today:
rob@rob-kubuntu3:~$ ypcat -d nisdom -h rhel5-64-2 passwd.byname
No such map passwd.byname. Reason: No such map in server's domain

It turns out this was a problem with the /var/yp/securenets file, but I’m still not sure what is wrong. The man page for ypserv shows:

A sample securenets file might look like this:

# allow connections from local host — necessary
host 127.0.0.1
# same as 255.255.255.255 127.0.0.1
#
# allow connections from any host
# on the 131.234.223.0 network
255.255.255.0 131.234.223.0

So we set up our securenets to look like this:

host 127.0.0.1
255.255.255.0 10.10.10.0

And tried to connect to the server:
rob@rob-kubuntu3:~$ ip addr show dev wlan0 |grep "inet "
inet 10.10.10.210/24 brd 10.10.10.255 scope global wlan0
rob@rob-kubuntu3:~$ ypcat -d nisdom -h rhel5-64-2 passwd.byname
No such map passwd.byname. Reason: No such map in server's domain
rob@rob-kubuntu3:~$ ping -c1 rhel5-64-2
PING rhel5-64-2 (10.10.10.213) 56(84) bytes of data.
64 bytes from rhel5-64-2 (10.10.10.213): icmp_req=1 ttl=64 time=0.823 ms

--- rhel5-64-2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.823/0.823/0.823/0.000 ms

Removing the /var/yp/securenets file allowed us access, so it wasn’t firewall or rpc or portmap issues, to the best I can determine. Adding “host 10.10.10.210” also worked and allowed the client access. So what’s wrong with the format / man page?

Upgrading software – always required to keep things secure. Windows, WordPress, Mac OSx, Linux, Office, Firefox, etc. So I just finished upgrading TotalNetSolutions.net again. Hopefully I’ll be able to be better about this, now that WordPress does the automatic upgrades now.

I’ve been doing the automatic upgrades on one of my other sites since they came out. They’re easy, fast, and even more painless than the 3-step upgrade that works so well. So now, I should be able to keep TNS much further away from the “cobbler’s kids” syndrome so many small company’s systems suffer with.

As of today:

“Akismet has caught 347 spam for you since you first installed it.”

That’s since 11/29/2007. Akismet has YET to miscategorize a comment as spam, and it has missed a single spam comment. All I had to do was click “this is spam” and it’s cleaned up.

The only other anti-spam product I’ve seen to perform this well is the IronPort mail system at a client. 130,000 or so attempts / day, 1 spam / day in the entire company queue, and no users complaining about spam in 5 months.

Akismet, Ironport, my hat is off to you both.

If you are setting up a cross-forest trust with selective authentication (which requires a Windows Server 2003 Native mode level forest and domain), don’t forget to grant the “Allowed to Authenticate” right to the users from the trusted domain to the servers they’ll need access to in your domain. The error messages you’ll get back (replicated here in my test VM domains) don’t really say much helpful.

System Error 317 has occurred. The system cannot find message text for message number 0x*** in the message file for ***.

System Error 317

Further information about adding the “Allowed to Authenticate” right to the trusted users is available at Microsoft TechNet. If you have the opportunity to raise your forest and domain functional levels to take advantage of this, I highly recommend it. But I recommend also (even more strongly) documenting precisely what you set.

Next Page »