2015-02-27

mod_remoteip backport for Apache HTTPD 2.2

Apache HTTPD 2.4 has a very useful new feature for large deployments: Replacing the remote IP of a request from a request header, e.g. set by a load balancer or reverse proxy. Users of Apache HTTPD 2.2 as found on RHEL6 can now use the backport found on https://github.com/ImmobilienScout24/mod_remoteip-httpd22.

I pulled this backport together from various sources found on the Internet and "it seems to work". Working with C code (which I did not do for 14 years!) tought me again the value of test driven development and modern programming languages. Unfortunately I still can't explain a change like this without a lot of thinking:
You can easily build an RPM from the code on GitHub. The commit history shows the steps I had to undertake to get there. Configuration is as simple as this:


LoadModule remoteip_module modules/mod_remoteip.so
RemoteIPHeader X-Forwarded-For
RemoteIPInternalProxy 10.100.15.33

with the result that a reverse proxy on 10.100.15.33 can set the X-Forwarded-For header. Apache configuration like Allow From can then use the regular client IP even though the client does not talk directly to the web server.

2015-02-18

Simplified DEB Repository



2 years ago I wrote about creating a repository for DEB packages with the help of reprepro. And since then I suffer from the complexity of the process and cumbersome reprepro usage:
  • Complicated to add support for new Ubuntu version which happens every 6 months
  • Need to specifically handle new architectures
  • I actually don't need most of the features that reprepro supports, e.g. managing multiple repos in one or package staging
This week I realized that for there is a much simpler solution for my needs: apt-ftparchive. This tool creates a trivial repo with just enough information to make apt happy. For my purposes that is enough. All what I want from a DEB repo is actually
  • Work well with 50-500 packages
  • Easy to add new Debian/Ubuntu/Raspbian versions or architectures
  • Simple enough for me to understand
  • GPG signatures
It turns out that the trivial repo format is enough for that, it makes it even simpler to add new distro versions because the repo does not contain any information about the distro versions. That means that the repo does not change for new distros and that I don't need to change the sources.list line after upgrades.

The following script maintains the repo. It will copy DEB packages given as command line parameters into the repository or simply recreate the metadata. The script uses gpg to sign the repo with your default GPG key. If you want to maintain a GPG key as part of the repo then you can create a key sub-directory which will be used as GPG home directory.


The script expects a config_for_release file in the repo that contains some extra information:

To add this repo to your system add something like this to your /etc/apt/sources.list:

2015-02-07

Ubuntu Guest Session Lockdown

The guest session is a very important feature of Ubuntu Linux. It makes it very simple to give other people temporary computer or Internet access without compromising the permanent users of the computer.

Unfortunately the separation is not perfect, the guest user can actually modify critical configuration settings on the computer and even access the files of the other users, if they don't take precautions.

The following scripts and files help to lock down the guest session so that no harm can be done.

How It Works

The guest session is actually a feature of the LightDM Display Manager that is used in Ubuntu and in Xubuntu. The guest session is enabled by default.

When a user chooses a guest session the following happens:
  1. LightDM uses the /usr/sbin/guest-account script to setup a temporary guest account. The home directory is created in memory (via tmpfs) and can occupy at most half the RAM of the computer.
    Optionally, /etc/guest-session/prefs.sh is included as root to further customize the guest account.
  2. LightDM starts a new session as this account.
  3. The guest account runs the /usr/lib/lightdm/guest-session-auto.sh start script.
    Optionally, /etc/guest-session/auto.sh is included to run other start tasks as the guest user.
The guest session behaves like a regular Ubuntu session including full access to removable storage media, printers etc.

Upon session termination LightDM uses the /usr/sbin/guest-account script to remove the temporary account and its home directory.

Securing Other Users

The default umask is 022 so that by default all user files are world-readable. That makes them also readable by the guest session user. For more privacy the umask should be set to 007 for example in /etc/profile.d/secure-umask.sh:

Preventing System Modifications

Much worse is the fact that by default every user - including the guest account - can modify a lot of system settings like the network configuration. The following PolicyKit Local Authority policy prevents the guest account from changing anything system related. It still permits the user to handle removable media and even to use encrypted disks. It should be installed as /etc/polkit-1/localauthority/90-mandatory.d/guest-lockdown.pkla:

Preventing Suspend and Hibernate

LightDM has IMHO a bug: If one opens a guest session and then locks that, it is impossible to go back to that guest session. Choosing "guest session" from the LightDM unlock menu will actually create a new guest session instead of taking the user back to the existing one. In the customization below we disable session locking for the guest altogether for this reason.

The same happens after a system suspend or hibernate because that also locks all sessions and shows the LightDM unlock login screen. The only "safe" solution is to disable suspend and hibernate for all users with this policy. It should go to /etc/polkit-1/localauthority/90-mandatory.d/disable-suspend-and-hibernate.pkla:

Customizing the Guest Session

To customize the guest session the following /etc/guest-session/prefs.sh and /etc/guest-session/auto.sh scripts are recommended. The prefs.sh script is run as root before switching to the guest account. It creates a custom Google Chrome icon without Gnome Keyring integration (that would ask for a login password which is not set) and disables various autostart programs from running. They are not needed for non-admin users.

This auto.sh script is run at the start of the guest session under the guest account. It configures the session behaviour. Most important is to disable the screen locking because it is impossible to return to a locked guest session. I decided to also completely disable the screen saver since I expect guest users to terminate their session and not let it run for a long time.

The other customizations are mostly for convenience or to set useful defaults:

  • Disable the shutdown and restart menu items.
  • Configure the keyboard layout with 2 languages (you probably want to adjust that as needed).
  • Show full date and time in the top panel.
  • Set the order of launcher icons in the Unity launcher.
It is fairly easy to find out other settings with gsettings list-recursively if required.

With these additions the guest session can be a very useful productivity tool. At our school the students use only the guest session of the Ubuntu computers. They got quickly used to the fact that they must store everything on their USB thumb drives and the teachers enjoy "unbreakable" computers that work reliably.