I.T. Security and Linux Administration

Jun 29 2011   11:46AM GMT

New checksum method

Eric Hansen Eric Hansen Profile: Eric Hansen

I got an interesting article in my inbox today in regards to using extended attributes to create checksums. While I don’t know if this will pick up to be a de facto standard way of distributing checksums, this is definitely a step in the right direction.

The article I got in regards to this uses Python to create an autonomous script to handle this. However, while that is find and dandy, I seek more pleasure in doing it in Bash. To make this easier to follow, I’ll be breaking it into steps.

Step 1: Ensure you can use extended attributes

I’m not sure if there’s some sort of universal method to doing this. However, I do know that it has to be part of the kernel (either by compiled in or by a module). The way I use is the following:

zcat /proc/config.gz | grep -i xattr

You should see some lines such as CONFIG_EXT#_FS_XATTR=y/n where # is 2-4, and y/n is either yes or no for whether its supported or not. Since I see ext2/3 used more than 4 in the real world, I’m going to assume the file system is 3 for this article. If you see CONFIG_EXT3_FS_XATTR=n then you will have to consult some on line documentation on how to enable XATTR support, as it is beyond the scope of this.

Step 2: Enabling your file system to use xattr’s

What I do for this is just edit /etc/fstab and add the “user_xattr” option. My line for the “/” partition looks like this:

UUID=6bcbfab5-5c4f-45c0-a2fb-a170b0bda3a1 / ext3 defaults,noatime,nodiratime,user_xattr 0 1

After this, reboot the machine. I’m sure there’s other methods (I’ve seen people do remounts like mount / -o remount,user_xattr) but I don’t trust them personally.

Step 3: Bash script and analysis

Create a file on the server, and put this code in it:

#!/bin/sh

FILE="$1"
SUM="$2"

if [ -z "$SUM" ]; then
        SUM="md5sum"
fi

if [ ! -f "$FILE" ]; then
        echo "File does not exist."
        exit 1
fi

CHKSUM=`$SUM $FILE | awk '{print $1}'`

setfattr -n user.$SUM -v $CHKSUM "$FILE"
getfattr -n user.$SUM "$FILE"

To use it, do the following (I named the file chksum.sh):
chksum.sh sum_test

Or, if you want a different checksum than MD5, do something like this:
chksum.sh sum_test sha512sum

The first two if blocks just check to see if we have a SUM (and if not, use MD5 as its more universal), and quit if the file don’t exist.

After that, it runs the checksum program against the file. Now, with testing, all the checksum programs seem to do the same . However, all we want is the hash. That’s why I have the output pipe through awk and only return the hash. This way, CHKSUM only has the hash itself.

Next, we run setfattr, which basically means set file attribute. This is the program that lets us set extended file attributes (I’ll go into more details of the “-n” switch next). Basically, the “-n” switch tells setfattr which namespace to store the attribute in. If the checksum is a MD5 hash, for example, then the namespace will be user.md5sum. The “-v” switch is the value to store in the specified namespace. The amount of data able to be stored is dependent on the file system. After that, we specify the filename where it will be stored.

When ran, you will see the following output:

./chksum.sh testing 
# file: testing
user.md5sum="893fcf14ce4e2f6e2cf441db1c560706"

Step 4: Explaining setfattr/getfattr (i.e.: extended attributes)

Extended attributes are stored in the meta data. This is the same area in data storage where the file’s permissions are stored. The downfall to this is that unlike permission meta data, extended file attributes aren’t supported without a kernel modification (see step #1). This limits the possibility of distributing checksums in a new manner.

If you’re curious why the namespace was “user”, here’s a good explanation I found from LinuxQuestions.org’s wiki:

The ‘user’ namespace. This is protected by the normal unix permission settings on the file (so having write access on the file also allows the user to set an extended attribute) and is meant to be used by the user and any application that is run by the user.
The ‘root’ or ‘system’ namespace, which can only be set with root access. ACL uses this namespace, it stores its access control lists in attributes like ‘system.posix_acl_access’ and ‘system.posix_acl_default’.
The ‘security’ namespace. For example, SELinux uses the ‘security.selinux’ attribute.

You can set the attribute to be any name you want, but it has to be prefixed with a user, root, or security namespace first. I see no reason using any other namespace than user currently, so I have left it as that. During some tests, though, I have found that the attributes do not carry over.

Article source: http://www.linux-mag.com/id/8794/?hq_e=el&hq_m=1280622&hq_l=10&hq_v=894b4354c7

 Comment on this Post

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to: