There are many applications that I use on my MacBook Pro — some free software, some shareware, some commercial (and downright expensive!). But there are just a few that I simply couldn't live without, and which deserve mention not only for their utility, but for excellence of thought and design as well. Read More...

Tags: Applications, Productivity

I just discovered a very cool feature of SSH today: control mastering. It lets you multiplex a single ssh connection so you don't have to open multiple TCP connections to the remote host; instead, all your SSH/SCP commands "share" the initial connection. This speeds up subsequent connections to the same host, and also means you don't have to enter your password more than once for hosts who don't know your public key yet. I use this feature to implement a script for setting up new remote accounts. Read More...

Tags: OpenSSH

About a half year ago I wrote a little Python module for myself to do "stateful" directory scans. This means keeping watch on the state of a directory so that you can act on changes, like files added or removed, files changed, etc. Now that I've been using this library every hour for that entire period -- with only a few minor bug fixes to cover some exceptional cases -- I believe that version 1.0 is ready for consumption. Today's article reviews the structure of this module and how to use it in your own, since I designed it with the full of intention of others being able to use it with their own scripts. Read More...

Tags: Filesystems

Today's article describes how to administrate OpenVPN on a Debian GNU/Linux server. It does not cover installing a new OpenVPN service from scratch, since that is already covered in the official OpenVPN 2.0 HOWTO. In particular, this document covers:

1. Logging in via OpenSSH to administrate the system.
2. Creating X.509 certificates for new OpenVPN users.
3. Installing the OpenVPN client on a user's machine.
4. Re-configuring OpenVPN and restarting the daemon.
5. Re-installing OpenVPN on a new Debian GNU/Linux server, in case the old server dies or is compromised.

If you haven't installed OpenVPN on your server yet, please visit the official HOWTO and complete the steps there. Then you can return to this document. I originally wrote this to show co-administrators how to work with an already-running OpenVPN installation. Read More...

Tags: VPN, OpenVPN

Today’s entry is a little primer I wrote for some co-workers at CEG, on setting up SVK to do remote development. We continue to use a central Subversion repository, but I often find myself working in cafés where I don’t have immediate access to the server. Also, I like to branch and check-in much more frequently than would be sane to do with Subversion — I also like the distinction between a “check-in” being a simple, quick snapshot, and an "svk push" as the real deal. Read More...

Tags: Versioning, Subversion, SVK, DVCS

One of the services I’m setting up on newartisans.com is Buildbot, so that every time changes get checked in the Ledger source tree, they’ll be automatically built and tested on every platform I have access to. Automatically. Without any intervention on my part whatsoever.

In terms of ease of use and assuring that things get done, Buildbot is a dream. In terms of system security, it’s a bit more of a nightmare.

Buildbot is a Python script that runs as a standalone daemon, listening for connections from the slaves in its network. Well, in terms of security I can never really trust a Python script. If anyone was able to subvert the code over the public TCP port, they could tell the script to do just about anything. It might not have much in the way of privilege, but at the very least it could read a whole lot of files on the system.

To run Buildbot securely means doing four things:

1. Freeze the Buildbot Python script in a single static binary, with no references at all to the system while running.

2. Run the server in a chroot jail, with access only to its own configuration files, its logs, and the state directories it uses to keep track of how the slaves are doing.

3. Run the server as the nobody user in the nobody group, so that it has the least permission possible.

4. Write an SELinux policy so that the daemon can only read and write exactly the files it needs to, and so it has permission to open a single TCP port and to send and receive traffic on that port.

With the environment set, a subverted daemon should just be a nuisance. The attacker could start instructing all of the slaves to keep building continuously, hoping to starve their system resources. And this can be alleviated by restricting builds to once daily. I’ll write more about the SELinux policy once it’s written.

Tags: Python, SELinux

The past few months have seen me digging deep into the world of TCP/IP and firewalls. It has been a fascinating journey into packet queueing and TCP headers, three-way handshakes and ICMP broadcasts.

The result of this research has been the ongoing creation of a firewall to protect my laptop against open networks, and my Internet server from port scanning and DoS attacks. I'm pretty certain I haven't even scratched the surface yet, but I have found some settings to protect against the most common attacks. In this article I summarize the major pieces of my new firewall, and the logic behind it. Read More...

Tags: Firewall, iptables

I started the adventure of writing an SELinux security policy from scratch today. This is on CentOS 5, which uses the new policy modules approach rather than the older scheme involved a huge number of policies and a Makefile.`

It took hours of searching on the Net to find out that there’s really nothing out there to teach you how to start a new policy from nothing. I found one “step-by-step” guide, but it involved using a GUI tool that I don’t have. Every other article on writing policy is about using audit2allow to make existing policies more permissive.

The missing piece turned out to be the package selinux-policy-devel, which installs a tree of macro files in /usr/share/selinux/devel. Going into there, I found a complete example policy! So I copied these example files and started configuring them for Trac, the Python daemon I want to lock down. After that, I just had to run make, and insert the new policy using “semodule -i trac.pp”. And now it looks like I’m in for a few days of tweaking, as I narrow down exactly what Trac does and doesn’t need to be able to do.

Tags: SELinux