(All commands below are executed as root.)

First I created a group to group them together and then added the users to that group. I choose to disable their password as I only allow logins using SSH keys.

addgroup sftponly
# Repeat the line below for each user
adduser --disabled-password --ingroup sftponly ausername

As for the upload directory I wanted them to upload their data to my raid1 volume mounted under /data/pool1. Since OpenSSH has some requirements for the permission on the directories used as chroot I created the following directory layout.

cd /data/pool1
mkdir -m 751 sftp
ln -s . sftp/home
# Repeat the lines below for each user
mkdir -m 700 sftp/ausername
chmod ausername.root sftp/ausername

The home symlink is there to make the initial SFTP directory /ausername and the sftp directory is created with 751 to disallow directory listing in the top directory.

Then, as “all components of the pathname must be root-owned directories that are not writable by any other user or group” and /data/pool1 is not root owned I created a bind mount by adding the following to /etc/fstab.

/data/pool1/sftp  /srv/sftp  bind  bind  0  0

Before the initial mount, the directory must be created.

mkdir /srv/sftp
mount /srv/sftp

Then, the final part was to configure OpenSSH by adding the following lines at the end of /etc/ssh/sshd_config.

Match Group sftponly
  ChrootDirectory /srv/sftp
  ForceCommand internal-sftp
  AllowTcpForwarding no
  X11Forwarding no

Remember to restart the server afterwards.

So I did:

sudo pbuilder create --debootstrapopts --variant=buildd

Building should then be as simple as executing:

git-buildpackage --git-builder=/usr/share/doc/git-buildpackage/examples/gbp-pbuilder --git-cleaner="fakeroot debian/rules clean"

Or it should have been that simple. Unfortunately the build failed with:

Fatal: no entropy gathering module detected

After some googling and testing; the fix was to add two random devices to the chroot:

sudo pbuilder login --save-after-login
mknod -m 666 /dev/random c 1 8
mknod -m 666 /dev/urandom c 1 9
chmod 666 /dev/null
exit

(The change of permission for /dev/null was needed to avoid getting errors later in the build process.)

I’m now officially the maintainer of Licq’s Debian packages. Since I’m not a real Debian maintainer, I’m very grateful to Joel Rosdahl who is my sponsor.

Version 1.3.8-1 is coming to a mirror near you as I write this.

The package source is kept in my git repository. To build the package from the git repository, install git-buildpackage and pristine-tar then follow the instructions below.

Initial setup:

% gbp-clone --pristine-tar git://git.ejohansson.se/debian/licq.git

% git clone git://git.ejohansson.se/debian/licq.git
licq % cd licq
licq % git checkout -b pristine-tar origin/pristine-tar
licq % git co master

To build the latest version:

licq % git-buildpackage --git-export-dir=../build-area

To build a specific version:

licq % git-buildpackage --git-export-dir=../build-area --git-export=debian/1.3.8-1

The final packages will be available in ../build-area.

Later on when you wish to update:

licq % git pull
licq % git-buildpackage ...

The next version will have qt4-gui.

In the BIOS, enable “Power on by PCIE device”.

In Linux, first install ethtool and then check that Wake on LAN is supported by running the following command:

root@host$ ethtool eth0
...
        Supports Wake-on: g
        Wake-on: g
...

The output should contain a ‘g’ to indicate that the device can be woken by sending it a “magic packet”.

Enable Wake-on by running:

root@host$ ethtool -s eth0 wol g

Since this command must be run on every boot, add it to /etc/rc.local.

root@host$ cat /etc/rc.local
...
ethtool -s eth0 wol g
exit 0

As the last step we must make sure that halt doesn’t disable the network device. This is done by adding this line to /etc/default/halt:

NETDOWN=no

We also need the MAC address to send the magic packet to.

root@host$ ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:1e:8c:cf:d0:bb  
...

Then shutdown the computer. On an other computer, install e.g. wakeonlan and run:

user@other$ wakeonlan 00:1e:8c:cf:d0:bb

The computer should now start.

Since libsepol1-dev ships with a static version of libsepol, I’ve also recompiled some of the packages that build-depends on libsepol1-dev and added them to the repository as well.

If you wish to use SELinux on you slug and feel that you trust me enough to use my version of this rather central piece of security software, add this to your sources.list:

deb http://eddie.ejohansson.se/debian/ etch main

The version number is the same as the version in etch with ‘a’ added at the end. Hopefully this means that when updated official packages are released they will automatically be upgraded.

If you want information on how to configure SELinux, this guide worked for me. But before you follow that guide (and after installing my updated packages), run ‘dpkg-reconfigure selinux-policy-refpolicy-targeted’ so that the base module and modules for the daemons you’re using are properly loaded.

For those of you that don’t know what DSPAM is:

DSPAM is a scalable and open-source content-based spam filter designed for multi-user enterprise systems. On a properly configured system, many users experience results between 99.5% – 99.95%, or one error for every 200 to 2000 messages.

If anybody is interested in my setup (Exim4+DSPAM+MySQL), let my know and I’ll publish my configuration files.

alias up='aptitude update && aptitude upgrade'

Now, up and enjoy the beauty of apt. Being a Debian administrator is sooo easy.

Since the first DSA in November 2000 (that’s when the first DSA was issued, Debian has been releasing security advisories since 1997) there has been a steady flow, with an average of 1 advisory every other day.

# ruby -rdate -e 'puts "DSAs/day: #{1000.0/(Date.parse("2006-03-14") - Date.parse("2000-11-29"))}"'
DSAs/day: 0.517866390471258
# ruby -e 'puts "Days between DSAs: #{1/0.517866390471258}"'
Days between DSAs: 1.931

We can also note that every year has seen more DSAs then the previous. This year does not seem to be any different. So far 72 advisories have been issued, which, by a strike of coincidence, is the exact same number as 2005 (up to March the 14th).

2000:  10
2001:  85
2002: 124
2003: 186
2004: 216
2005: 307
2006:  72

Continuing on the date statistics, we see that January is, by far, the month with most advisories (153). Followed by October (96) and February (94). Interesting is also the fact that the late spring and summer months July (72), June (62) and May (40) comes furthest down in the result list. It would seem that even security experts prefer the sun to the computer. Nah, proably purely coincidental. Everybody knows that computer geeks prefers the screen and its friendly glow

The most popular date is, far from surprisingly, in January. Namely the 23th (12) with three advisories more than any other day.

Top 10

But, let us leave the dates and move on to something more interesting: Top 10.

Vulnerabilities

The top 10 vulnerabilities is given below (the number is the number of DSAs tagged with the vulnerability).

173 - buffer overflow
130 - several vulnerabilities
 57 - buffer overflows
 37 - missing input sanitising
 37 - insecure temporary file
 27 - insecure temporary files
 27 - programming error
 23 - denial of service
 22 - integer overflow
 18 - format string

The most common vulnerability is not surprisingly buffer overflows, followed by insecure temporary files and missing sanitising of input. All three classic security issues.

Packages

The 16 (only 10 would have excluded packages with the same number of advisories as some that where included) packages with the most advisories are given below.

13 - ethereal
13 - kdelibs
11 - squid
10 - cvs
 9 - mysql
 8 - krb5
 8 - cupsys
 8 - heimdal
 8 - samba
 7 - sudo
 7 - tcpdump
 7 - xfree86
 7 - xpdf
 7 - apache
 7 - openssl
 7 - fetchmail

These numbers are actually a bit suprising. I can understand that kdelibs, mysql, cupsys, samba, xfree86 and apache are included since they are pretty big. But what’s ethereal, cvs, tcpdump, xpdf and fetchmail doing there? I don’t think they are big enough to justify theire appearance among the top (bottom?) 10.

We close this post with the top packages, counting only 2005 and 2006. Much the same as the previous, but now with squid as the leader and courier and firefox joining in.

7 - squid
5 - clamav
4 - courier
4 - ethereal
4 - xpdf
4 - mozilla-firefox
4 - kdelibs

Disclaimer: I know it’s unfair to just list the packages with the most advisories. I should proably dig deeper and compare the count to the impact each vulnerability had. But I don’t have the time to do so now and my tiny DSA statistics script doesn’t do it for me. So take the data presented here (as the Swedish saying goes) with an ounce of salt.

Digg This Article