Chroot’ed BIND and Apparmor

Recently I set up a server running BIND on my network to serve as at alternative to updating host files for my VM’s…  previously I accomplished this via Puppet and it worked OK but needed to be changed.  There were some minor additions to the how-to to get it working for me in the chroot, most of them were related to Apparmor profiles but some libraries were needed as well.

These notes are assuming you’re running under Ubuntu 12.04 LTS, earlier releases (or later ones) will have different requirements.  I’m also using /var/chroot/named as the path for the chroot.

Once you create the chroot environment, you’ll need OpenSSL libraries:

# mkdir -p /var/chroot/named/usr/lib/x86_64-linux-gnu/openssl-1.0.0/engines
# cp /usr/lib/x86_64-linux-gnu/openssl-1.0.0/engines/libgost.so /var/chroot/named/usr/lib/x86_64-linux-gnu/openssl-1.0.0/engines

Then the Apparmor profile must be updated to reflect the chroot and library.  I just created a new file under ‘local’:

root@ns1:~# cat /etc/apparmor.d/local/usr.sbin.named 
# Site-specific additions and overrides for usr.sbin.named.
# For more details, please see /etc/apparmor.d/local/README.
#

# named chroot
/var/chroot/named/** r,
/var/chroot/named/etc/bind/** r,
/var/chroot/named/var/lib/bind/ rw,
/var/chroot/named/var/lib/bind/** rw,
/var/chroot/named/var/cache/bind/ rw,
/var/chroot/named/var/cache/bind/** rw,

/var/chroot/named/var/run/named/named.pid w,
/var/chroot/named/var/run/named/session.key w,

/var/chroot/named/usr/lib/x86_64-linux-gnu/openssl-1.0.0/engines/libgost.so rm,

Don’t forget to restart Apparmor for the changes to take effect!

Remote monitoring with apticron and logcheck

I wanted to write a brief posting on some basic ways to help remotely administer Ubuntu/Debian boxes.  Over the past few months I’ve been tinkering with various methods of handling this and what I’ve come up with seems to work fairly well.  It basically consists of two applications: apticron, which monitors repositories for package updates, and logcheck, which monitors logs in for any security or other noteworthy entries.

Apticron is very easy to set up, it’s in the repositories and requires basically no configuration.  It will drop a script in /etc/cron.daily and that is about it, emailing any reports to root.  Of course this can be modified through a .forward or an entry in /etc/aliases.

Logcheck is fairly simple to set up as well – it is also in the repositories.  Once installed, edit the /etc/logcheck/logcheck.conf file to configure.  The first thing you will want to set is the REPORTLEVEL setting, options are “workstation”, “server” (default value), or “paranoid”.  I use server on mine, which gives a good amount of detail. I would advise against using paranoid unless the server is extremely locked down and users do not typically login.  Workstation is good for a desktop environment.  The only other variable I edited was SENDMAILTO.  Logcheck works by basically comparing each  logentry against a set of regular expressions and generate a report if it does not match.  I had to modify one or two regex’s slightly to fix false positives, if you want my changes just ask and I’ll send them over.

One other small gem I want to mention : gkrellm.  I use this on both my desktop and server, it is invaluable for providing real-time system performance metrics.  Sure, it does not have any logging capabilities and thus unsuitable in a large-scale environment but for keeping an eye on one or two boxes it fits the bill quite nicely.

Simple key-based SSH + service account HOWTO

If you have read my brief posting Intrepid upgrade done I mentioned I would shorlty be implementing SSH keys for my systems.  This is a simple HOWTO to cover the steps I used.  In my case I’m implementing this only a small home network, please adjust as needed.  I will be setting up a key for my primary user account plus an additional phrase-less key used for automation purposes.  This second key will act as a service account, restricted to running only a few particular applications and/or scripts.

  1. Run ssh-keygen -t rsa.  I specified a simple passphrase for general-purpose logins.  We will be adding the second phrase-less key later.
    (adechiaro@desktop:pts/6)-(4/0 @ 17k)-(09:22 PM)
    ~$ ssh-keygen -t rsa
    Generating public/private rsa key pair.
    Enter file in which to save the key (/home/adechiaro/.ssh/id_rsa):
    Enter passphrase (empty for no passphrase):
    Enter same passphrase again:
    Your identification has been saved in id_rsa.
    Your public key has been saved in id_rsa.pub.
    The key fingerprint is:
    5d:34:f1:de:ad:be:ef:65:34:36:a4:0d:75:d6:3c:47 adechiaro@desktop
    The key's randomart image is:
    +--[ RSA 2048]----+
    ...
    +-----------------+
    (adechiaro@desktop:pts/6)-(4/0 @ 17k)-(9:22 PM)
    ~$ cat .ssh/id_rsa.pub
    ssh-rsa <key> adechiaro@desktop
  2. Any machine you want to be able to connect to with this key, login and copy the contents of your public key (id_rsa.pub) to the authorized_keys file.  These are all in your $HOME/.ssh/ directory.  There are various ways to do this: you could copy the file over with scp and cat/append it, you could remote in to the host and cut & paste the data, if you had a large infrastructure you could use ssh-copy-id or similar custom script.  It’s up to you, something like what is below should work in the general case.  Also the <key> is your public key in base64 encoded format.
    desktop:~$ scp .ssh/id_rsa.pub adechiaro@server:~
    id_service.pub                           100%  399     0.4KB/s   00:00
    desktop:~$ ssh adechiaro@server
    server:~$ cat id_rsa.pub >> ~/.ssh/authorized_keys
  3. Now for an example of making the key more secure, you can add additional options to the authorized_keys file.  These come before the “ssh-rsa <key>” part of the entry (prefix the line with them): Continue reading

Read-only bind mounts will finally be available in Ubuntu! (with Ibex)

Finally!   After awaiting a solution for sometime to be released, Ibex will  have kernel 2.6.26 which  supports read-only bind mounts.  I discovered this as a rather serious security breach to my proposed system design  some time ago – I was trying to implement remote access for myself and friends to my data storage.  I figured some form of SSH-based access would be a good start, but I didn’t want to have any accounts directly open on my server or desktop machine.  Since building separate physical hardware just for this would be a waste of resources, I thought the best solution would be a virtual machine.  Configuring NFS on it could potentially be another security hole (not to mention more overhead then needed), I knew a bind mount would be perfect – a read-only one of course.  However as I was testing it I quickly realized that read-only bind mounts weren’t actually read-only.  Thus, the problem.  I suppose since I keep most of my multimedia files marked immutable it wouldn’t be a real problem unless someone got root.  Still rather be safe then sorry.  More to follow about this later.

I read over a few postings to the kernel mailing list which addressed this last year, but this was just in the development phase then.  The solution the kernel architects created involved updating the VFS code, since all bind mounts are implemented in the virtual layer.  You can read more of the technical aspects over at lwn.net.