Category Archives: Internet, Unix en security

SpamAssassin to blacklist and unblacklist

SpamAssassin has a feature to blacklist and unblacklist certain e-mailaddressen. But recently I noticed something interesting that may need some more investigation. I have all addresses for domain example.org blacklisted, but also unblacklisted certain functional addresses as is shown in the example below.

blacklist_from          *@example.org
unblacklist_from        abuse@*
unblacklist_from        hostmaster@*
unblacklist_from        postmaster@*
unblacklist_from        security@*
unblacklist_from        webmaster@*

Now I expected that webmaster@example.org was going to be unblacklisted, meaning the mail would have both a spamscore of both +100 and -100 making it effective 0 again. This modification resulted in a spamscore of +100 and makes me worry that unblacklisting will demand that the domain part needs to be specified instead of having a wildcard. This will require some more testing in the near future, but for now it may affect other installations.

Getting Ext3/4 journal size

Ext3 is an successor of Ext2 with support for journaling which means it can have a log of all it’s recent changes it made or is going to make to the file system. This allows fsck to get the file system back in a good state when a power failure happens for example. But what is the size of the journal? Reading the manpage for tune2fs it says it needs to be between 1024 and 102400 blocks which means it can start with 1MB on a file system with a 1KB block size and 4M on a file system with 4KB a block size.

So let start to see which inode contains the journal and normally this should be inode 8 unless you have a file system that was upgraded from Ext2 to Ext3/4.

$ sudo LANG=C tune2fs -l /dev/sda1 | awk '/Journal inode/ {print $3}'
8

Now that we have the inode responsible for the in file system journal we can retrieve it details by doing a stat() with debugfs for that inode. Debugfs retrieve the details from the inode and on of them is de allocated size on disk.

$ sudo LANG=C debugfs -R "stat <8>" /dev/sda1 | awk '/Size: /{print $6}'|head -1
debugfs 1.42.4 (12-Jun-2012)
4194304

Now let use the same procedure on an other file system:

$ sudo LANG=C tune2fs -l /dev/mapper/data00-srv | awk '/Journal inode/ {print $3}'
8
$ sudo LANG=C debugfs -R "stat <8>" /dev/mapper/data00-srv | awk '/Size: /{print $6}'|head -1
debugfs 1.42.4 (12-Jun-2012)
134217728

There is also an easy way as dumpe2fs provides an interface to a lot of these values directly.

$ sudo LANG=C dumpe2fs /dev/mapper/data00-srv | grep ^Journal
dumpe2fs 1.42.4 (12-Jun-2012)
Journal inode:            8
Journal backup:           inode blocks
Journal features:         journal_incompat_revoke
Journal size:             128M
Journal length:           32768
Journal sequence:         0x0111fd4c
Journal start:            3380

Keep in mind that changing something on a live journal can destroy your file system, so never move the journal location or change it’s size unless it’s a clean unmounted file system.

BtrFS as ongoing project

BtrFS is still an ongoing project for me, but if it will become a production platform for me soon is the question. Also playing with mirroring on BtrFS level made me wonder even more as it does the calculating about storage usage a little bit differently. Normally with mirroring you see the storage you can allocate and has been allocated. With BtrFS you see the total amount of data available on all disks combined as show in the example below.

$ sudo btrfs filesystem df /mnt
Data, RAID1: total=5.98GB, used=5.36GB
System, RAID1: total=8.00MB, used=4.00KB
System: total=4.00MB, used=0.00
Metadata, RAID1: total=256.00MB, used=6.01MB
$ df -h /mnt
Filesystem                Size  Used Avail Use% Mounted on
/dev/mapper/vg01-btrfsm1   16G   11G  4.8G  70% /mnt

I really like ZFS, but I really wonder if BtrFS could replace it. For now I see too many drawbacks in how BtrFS has been implemented and how distributions may use it. Maybe when Debian 8 is in testing it may be a better time to give BtrFS another chance, but swap space and encrypted file systems are still problems that need to be tackled.

A /tmp for every user

With the transition towards /run some temporary files will move towards /run/user/, but enough files remain in /tmp. Files that may leak information or be a point of code injection as shown with CVE-2012-3355. A first step is to create a temporary directory for every user when he or she logs in to restrict exposure of temporary files.

After installing the right module for PAM and enabling it, every user that logs in will get it’s own directory for temporary files. In this case based on the users ID-number, but still only accessible for the user themself.

$ sudo apt-get install libpam-tmpdir
$ sudo pam-auth-update --package tmpdir
$ ls -l /tmp
totaal 0
drwx--x--x 4 root       root       80 jun 24 22:01 user
$ sudo ls -l /tmp/user
totaal 0
drwx------ 2 root    root     40 jun 24 22:00 0
drwx------ 2 user1   users    40 jun 24 22:06 1000
drwx------ 2 user2   users    40 jun 24 22:03 1001

Files and directories that still remain in /tmp after this may ask for additional attention as the path to /tmp appears to be hardcoded. A small bugreport may be in order to just move away from hardcoded paths as in most cases they also indicate a hardcoded file for all users on the system.

Create home directory on first login

Creating home directories for new users can be a difficult task and specially in a LDAP-based environment, but most PAM installations have the option to create a new home directory before the user logon is completed. Debian also ships the module mpam_mkhomedir, but without a manifest to set it up correctly. Bug 640918 covers this issue, but for now creating the file /usr/share/pam-configs/mkhomedir with the content below resolves the problem.

Name: Create home directory on first login
Default: no
Priority: 0
Session-Type: Additional
Session-Final:
 required pam_mkhomedir.so umask=0027

After creating the file, the command below updates the PAM-config to create the home directory when a users home directory doesn’t exist. In the example configuration above the default umask is 0027 so only the user and group will have access to the home directory.

$ sudo pam-auth-update --package mkhomedir

By default the configuration in /etc/skel is being used to create a new home directory. This is a point of attention when the user needs files and/or directories when the user logs in and an example of this may be a Maildir for receiving mail.