Chkrootkit and other tools that scan for rootkits sometimes report a python related ‘.path’ file as suspect.

Example:

/usr/lib/pymodules/python2.6/.path

The script/binary responsible for creating that file is /usr/sbin/update-python-modules

from the Debian & Ubuntu package python-support

code extract from /usr/sbin/update-python-modules

There is no harm in understanding how to adapt chkrootkit or alternatives to ignore a list of locally recognised false positives, however some might consider this ‘false positive’ a bug.

Advertisements

During 2010 I will be migrating several servers from Debian Lenny to Debian Squeeze.

Here are some short points based on my experiences in migrating the first couple of servers to Debian Squeeze

Dependency based boot sequencing:

Debian squeeze uses dependency based boot sequencing by default.

If you are doing a new install then this will not an issue, however if you are upgrading from Debian Lenny then you will be prompted to make a decision during the upgrade.

Debian will do its own check before prompting you

info: Checking if it is safe to convert to dependency based boot.

Here is an example of how you will be prompted:

The boot system is prepared to migrate to dependency-based sequencing. This is an irreversible step, but one that is recommended: it allows the boot process to be optimized for speed and efficiency, and provides a more resilient framework for development. A full rationale is detailed in /usr/share/doc/sysv-rc/README.Debian. If you choose not to migrate now, you can do so later by running “dpkg-reconfigure sysv-rc”.

If you are running a dedicated server then dependency based boot sequencing may give a slightly quicker boot time, so you might see your server come to life a bit quicker after a reboot.

If you are running a VPS then your decision might involve some further consideration (see later paragraph)

Kernel versions, release dates, general usage:

Version        Released         General Usage
2.6.27         Late 2008        2009
2.6.18         Late 2006        2007

My intention here is to illustrate just how old Kernel 2.6.18 is (even though it still use today by some VPS container software).

If you are interested in more precise dates then the following links might be a start:

udev changes and Kernel 2.6.27 or newer is recommended:

Upgrading udev to the Debian Squeeze version, you will see some or all of the following messages:

Reboot needed after this upgrade

You are currently upgrading udev using an incompatible kernel version. A compatible version is installed or being installed , but you need to reboot using this new kernel as soon as the upgrade is complete. Without a reboot with this new kernel
version, the system may become UNUSABLE.

Here is a short discussion on why (after rebooting) your system booting Kernel 2.6.27 or newer is required.

If you have your own upgrade approach (rather than following the upgrade guide exactly), then you may choose to ensure the required newer kernel is manually installed yourself.

Running a VPS and further considerations:

  1. Does my VPS provider (and container software) list Debian Squeeze in supported install operating systems?
  2. Has Debian Squeeze been officially released yet?..if it has not then you might want to be as conservative as possible in your choices.
  3. Does the VPS container software run a recent kernel (2.6.27 or newer)?

In particular, unlike a dedicated server, when running some VPS, your system facilities might depend on the Kernel version of the container software.

Read the upgrade guide – essential reading:

If you read nothing else then at least help aptitude and apt work through your packages properly.

Extra notes and links for Amazon EC2 and Rackspace Cloud:

If Amazon EC2 do stick with using Kernels from Fedora core, then ideally FC10 kernel rather than the aged FC8 kernel might give better compatibility with Debian Squeeze.

Based on the small amount of reading I have done, EC2 is not really a great environment to go with Debian Server images, but it can be done with some perseverance.

Perhaps Rackspace Cloud Servers might be a better alternative if you really want Debian (Lenny) from a drop down list rather than messing about.

If you want to run ahead and deploy Debian Squeeze in any cloud, ahead of its official release, then support for any issues you have will be difficult to come by.

There are many articles about securing /tmp
by having it on a separate disk and mounting it noexec.

When this is done (sometimes a datacentre might do it for security), on debian this can cause an issue.

When apt is preparing to install it will often try and extract package contents to a temporary directory.

By default /tmp will be used unless you tell your system otherwise.

So the advice I found in the comments of another article mentioned the following:

APT::ExtractTemplates::TempDir "/var/tmp";

…but where to put it?

Here is how I worked it.

Apt needs telling that you want to use somewhere other than /tmp as the place where it should extract package files during installation.

You want to set this as a permanent setting on your server.

Preferences for how apt should behave on a Debian Lenny system are in/etc/apt/apt.conf.d/ and so create a file named 50extracttemplates in that directory that looks like the following:

APT
{
  ExtractTemplates
  {
	TempDir "/var/local/tmp";
  };
};

Here I have set it to /var/local/tmp as my datacentre, in order to be super secure 🙂 also sets /var/tmp as noexec.

( Here is a copy of my 50extracttemplates file if you prefer to download rather than copy and paste )

Change what I have in my file to /var/tmp if that is okay for your setup, or if you want to stay with /var/local/tmp then ensure you have created that directory and given it the appropriate permissions.

To help identify where this error/restriction might appear on your system I now give two sample outputs of a package install of bind9. The first illustrates the problem. The second shows different behaviour now that apt is happier extracting things.

Problem:

The following NEW packages will be installed
  bind9
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 0B/255kB of archives.
After this operation, 778kB of additional disk space will be used.
Preconfiguring packages ...
Can't exec "/var/tmp/bind9.config.326141": Permission denied at /usr/share/perl/5.10/IPC/Open3.pm line 168.
open2: exec of /var/tmp/bind9.config.326141 configure  failed at /usr/share/perl5/Debconf/ConfModule.pm line 59
bind9 failed to preconfigure, with exit status 255

…and now with the fix in place…

The following NEW packages will be installed
  bind9
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 0B/255kB of archives.
After this operation, 778kB of additional disk space will be used.
Preconfiguring packages ...
Selecting previously deselected package bind9.

which looks a lot healthier.