The user sees

You register your fingerprint using the built in reader and it saves it as your password. Next time you go to login you choose your username, swipe your finger and the PC verifies it against the one you scanned last time. If it matches then the computer logs you in.

What actually happens

1. You open up the fingerprint reader application on your laptop, it adds hooks into the Windows login system (Credential Providers).
2. You scan in one or more fingers and register them to your account.
3. The application stores the fingerprints for later use, some will even store them unencrypted.
4. When the user goes to login next time they select their username and scans a finger.
5. The fingerprint reader takes the scan and compares it to the previous scan
6. If the scan matches one of the stored scans then the user is authenticated

Why its not secure

How often do you write down your password? If you do where would you leave it? Now think about your fingerprint. Where would you leave your fingerprint? In general people don’t constantly where gloves and end up leaving fingerprints all over the place, on glasses, door handles, keyboards, touch screens and mobiles. It is a little bit harder to copy a fingerprint but security by obscurity is not an excuse. So it can be argued that a password is more secure (in that its harder to obtain) than a fingerprint.

Most fingerprint authentications allow you to use either your fingerprint, or your password. This effectively doubles the possible attack vectors for trying to get into the system. A malicious attacker can now either use a dictionary attack against your password, a fingerprint based attack against the fingerprint reader, or look for holes in either system.

Why it may actually endanger you

Do you know how the fingerprint reader is storing your fingerprints? Is it storing them as bitmaps, as a collection of swirls and whorls or as a md5 hash or some key identifiable features? If you can’t answer that question with 100% certainty then you should be concerned. If someone managed to hack your machine and retrieve bitmaps of your fingerprints then they could use them to open any other fingerprint locks you have, or implicate you in a crime.

Finally if someone is determined enough to break a law to hack your computer they could simply cut off your fingers to gain access to your PC. Of course if the fingerprint sensor has a warmth sensor they might need to microwave them first. I would hope though that you keep something that sensitive or valuable under all sorts on encryption and armed guards.

Don’t rely on fingerprint readers for added security, that is quite simply not the case. Fingerprint readers are primarily for convenience, and they could put your security and your wellbeing in danger.

Random Thought: What is this obsession with altering perfectly fine machines to remove an component that never bothers anyone? Dyson has the bladeless fan, and recently we’re seeing the spokeless bike. Have you ever looked at a fan and said: “Those blades really make that fan so annoying!”?

A daemon is a program that runs in the background. A daemon will usually be started at system startup and end at system shutdown. The exceptions to this rule are programs like the Bluetooth SDP daemon, which is activated when a new Bluetooth HCI is found,, and ends when it is removed. Daemons run transparently and do not normally interact with the user directly.

Daemons start as ordinary processes but they eventually ‘fork and die’ to start running in the background. Some daemons do only the ‘fork and die’ step but ignore other important steps. Here is a list of what a daemon should do:

1. Fork to create a child, and exit the parent process.
2. Change the umask so that we aren’t relying on the one set in the parent.
3. Open logs to write to in the case of an error.
4. Create a new session id and detach from the current session.
5. Change the working directory to somewhere that won’t get unmounted.
6. Close STDIN, STDOUT and STDERR.

These steps ensure that our association with the calling environment is destroyed and our daemon is now free to run as a completely separate process.

Lastly before writing the daemon you should make sure the code is written securely and in a way that fails gracefully. If your daemon crashes it will not be able to prompt the user about what action to take. The user may not even notice until it is too late.

Forking a child process

In Unix fork() is the only system call with two return values. When you call fork a child process is created which is a near copy of its parent (some things will be different in the child eg. process id). The fork command then returns a 0 in the child and the childs process id in the parent, on failure a -1 is sent to the parent. Generally a program will then check whether it is the child or parent by these return values (just like in movies when a cloned character will check to see if he has a belly button and hence is the original). Here is a snippet of code to do this:

pid_t pid;

/* Clone ourselves to make a child */
pid = fork(); 

/* If the pid is less than zero,
   something went wrong when forking */
if (pid < 0) {
    exit(EXIT_FAILURE);
}

/* If the pid we got back was greater
   than zero, then the clone was
   successful and we are the parent. */
if (pid > 0) {
    exit(EXIT_SUCCESS);
}

/* If execution reaches this point we are the child */

Changing the umask

Because we are a clone of our parent we’ve inherited its umask. This means the child doesn’t know what permissions files will end up with when it tries to create them. We do this by simply calling umask like this:

/* Set the umask to zero */
umask(0);

Open logs to write to

This part can be done in several different ways. You could open text files, log to a database or use syslog. The method I’m going to demonstrate here is to log using syslog. Syslog sends your log messages to a system wide logger, where they can be configured to be written to a file, send to a network server or filtered away entirely.

/* Open a connection to the syslog server */
openlog(argv[0],LOG_NOWAIT|LOG_PID,LOG_USER); 

/* Sends a message to the syslog daemon */
syslog(LOG_NOTICE, "Successfully started daemon\n"); 

/* this is optional and only needs to be done when your daemon exits */
closelog();

Create a new session id

Each process on a Unix system is a member of a process group (or session). The id of each group is the process id of its owner. When we forked from our parent earlier we will have inherited its process group, and our process group leader will still be its parent process. We want to create our own process group and become our own process leader otherwise we will look like an orphan. We can do this easily as follows:

pid_t sid;

/* Try to create our own process group */
sid = setsid();
if (sid < 0) {
    syslog(LOG_ERR, "Could not create process group\n");
    exit(EXIT_FAILURE);
}

Changing the working directory

At the moment we have the working directory we inherited from our parent. This working directory could be a network mount, a removable drive or somewhere the administrator may want to unmount at some point. To unmount any of these the system will have to kill any processes still using them, which would be unfortunate for our daemon. For this reason we set our working directory to the root directory, which we are sure will always exist and can’t be unmounted.

/* Change the current working directory */
if ((chdir("/")) < 0) {
    syslog(LOG_ERR, "Could not change working directory to /\n");
    exit(EXIT_FAILURE);
}

Closing the standard file descriptors

A daemon doesn’t interact with the user directly it has no use for STDIN, STDOUT and STDERR and we really have no idea where these are connected or where anything we write to them will end up. As these file descriptors are not required and effectively useless we should close them to save some system resources and prevent any related security problems. We close these descriptors like this:

/* Close the standard file descriptors */
close(STDIN_FILENO);
close(STDOUT_FILENO);
close(STDERR_FILENO);

Writing the payload

Now you have a C program that is capable of becoming a daemon, but its a pretty useless daemon if it exits immediately. Payload code is really up to you to design. I’ll offer you a few tips on designing your payload.

• Put your payload in a loop. Generally in a daemon you want to perform the same action over and over again until you’re killed. If you have to cleanup (such as closing syslog) when the daemon is about to be killed you should add an exit clause that will be activated by a SIGTERM signal handler.
• Make your code as fast an efficient as possible. This is something you should do with any program, but with daemons it is important that you do not hamper the performance of the rest of the system. This is especially true if you’re going to be running this daemon on desktop systems.
• Be aware that your code may be preempted very often. As your daemon is going to be running for the amount of time the system is up, it is likely that its execution will be preempted.
• Be paranoid about security. Daemons are common attack vectors and can be used to gain privileged access to a system. You should consider dropping any privileges that you don’t require.

Conclusion

So if we take all the code I’ve mentioned in this post and put it all together you have a simple daemon. You can download the source from the link here: daemon.c.
If your daemon is only going to be run on Linux and not on a System V style system such as Solaris you can use the daemon function to do a lot of this work for you.

References

Linux Daemon Writing HOWTO in C
Linux Daemon writing in C++

Random Thought: It appears the devil uses a Unix based OS, probably OSX.

mysql> SELECT time, temp, humidity FROM sensor_outside
       WHERE time > '2009-11-26 14:39'
         AND time < '2009-11-26 14:53';

+---------------------+------+----------+
| time                | temp | humidity |
+---------------------+------+----------+
| 2009-11-26 14:39:02 |   30 |       40 |
| 2009-11-26 14:39:39 | 29.6 |       40 |
| 2009-11-26 14:40:16 | 28.9 |       40 |
| 2009-11-26 14:40:53 | 28.4 |       41 |
| 2009-11-26 14:41:30 | 27.9 |       45 |
| 2009-11-26 14:50:08 |   20 |       83 |
| 2009-11-26 14:50:45 |   20 |       84 |
| 2009-11-26 14:51:22 | 19.9 |       85 |
| 2009-11-26 14:51:59 | 19.8 |       85 |
| 2009-11-26 14:52:36 | 19.7 |       86 |
+---------------------+------+----------+
10 rows in set (0.00 sec)

• Subversion allows you to work on the same assignment on multiple computers.
• Subversion can email you with changes you’ve made, allowing to review them.
• Subversion allows you to show a teacher that you’ve been working on an assignment over the whole time available and not just in the last few days. this gives you greater leverage when asking for an extension.
• Subversion can help you prove in a disciplinary hearing that you did not plagiarise any code from others showing the natural growth your code had.
• Subversion can get back that file you just accidentally emptied out of the trash.
• Subversion can show you all the changes you made between the time you fixed that annoying bug, and now, when you just reintroduced it.

The first step to making an assignment in is to build your repository. If you didn’t do this first that’s okay, you can easily import an existing project into a subversion repository. To create a repository you simply use the ’svnadmin create’ command. You should then create some folders that should be in every subversion repository (trunk, tags and branches). This next block of commands will show you how to create the initial project. If you’re using these instructions to import an existing project just copy your files into the trunk folder before you run the ’svn import’ command.

mkdir -p /home/daniel/svn/newproject
svnadmin create /home/daniel/svn/newproject
mkdir -p /tmp/newrepo/{trunk,branches,tags}
svn import /tmp/newrepo file:///home/daniel/svn/newproject -m "Create Initial Structure"
rm -rf /tmp/newproject

The trunk, tags and branches folders aren’t strictly required but can be very useful in certain circumstances. The trunk folder is where you main copy sits, it should be the latest stable version of the software. In an assignment though this is where you will probably be doing all your work, you generally don’t have the need or the time to make and merge branches. Which leads us to branches. Generally you branch software when you are about to make a major change that may break other developers work. You most likely don’t have other developers on your assignment and if you do you’ve probably all decided on what parts you will work on. Finally tags are for labelling certain versions with a specific tag. For example if you have to submit your assignment weekly you could tag each week as you submit, or you could tag as you finish each requirement. To populate these folders you just copy whatever it is you want into them. Subversion will only use a minuscule amount of space as the copy will be stored internally to the repository.

Before you can edit the files in the repository you need to check it out. You can check it out to the same machine, you can use SSH or you could check it out over WebDAV depending how you’ve set it up. The following command checks out the trunk folder into a folder called newproject. This is one of the few times you have to type the full path to the repository. Subversion remembers this for you so that next time you use a subversion command its pre filled.

svn checkout file:///home/daniel/svn/newproject/trunk newproject

What you’ve just checked out is called a ‘working copy’. This is where you make your changes before uploading them again in to the repository. Your working copy also includes copies of the versions you originally checked out so that if you want to revert back to them you can. Because they are stored in the working copy you don’t need access to the repository to revert. To revert back to the version you checked out from the repository you simply run ’svn revert <filename>’. You can also find the differences between these versions and the current ones by using ’svn diff <filename>’. The filename is optional and if omitted will print all the changes in the current directories and below.

Part 2 to come…
Random Thought: I’ve just redesigned my website, I’d love to know what my readers think. If you could post your comment on the new design, I’d appreciate it.

Generics and parametrized classes allow Java programmers to place a type on a class and have that type inherited by its methods. For example you can now declare an ArrayList class with a type String. This alters the ArrayList class so that its add method now only accepts objects of type String, the get method now also returns objects of type String. This makes everything type safe which means you don’t have to cast anything and your code won’t compile if you try to put something in the ArrayList that doesn’t match its class.

Java uses parametrized classes to build its collections and you’ll want to use them too if you’re making your own collection class. For example if you were implementing a stack, a queue or a multi-priority FIFO queue are good cases for parametrized classes. Be careful though of the lure parametrized classes can have. They are not a replacement for polymorphism and shouldn’t be used when polymorphism would make more sense. For example if your multi-priority queue gets the priority out of the object itself then you’d need an interface that provides a method to get the priority. Then your class will only be able to accept items that implement that interface, which makes sense in this case as we need to priority to be able to store it.

A parametrized class is really simple to use. Here is an example implementation of a stack collection backed by an ArrayList:

import java.util.ArrayList;
import java.util.Collection;

/**
 * This class acts as a stack. Items can be 'pushed' which adds them to the top
 * of the stack. items can also be 'popped' which removes and returns the top
 * item on the stack and removes it. This means only the most recently added
 * item is available at the current time. To get to older items you need to
 * first remove the others.
 *
 * Note: Java already has a stack object that should probably be used in
 *       preference to this one. This is only an example implementation.
 *
 * @author Daniel Hall <daniel@danielhall.me>
 *
 * @param <T> The type of items that can be stored in the Stack.
 */
public class Stack<T> {
	/* Uses the same type as this class to store the items */
	private ArrayList<T> array = new ArrayList<T>();

	/**
	 * Creates a Stack containing items already in a collection. The collection
	 * must have the same parameterized type as this class to ensure that we get
	 * the right objects.
	 * @param c The Collection to initialize with
	 */
	public Stack(Collection<T> c) {
		array.addAll(c);
	}

	/**
	 * Creates an empty Stack object
	 */
	public Stack() {

	}

	/**
	 * Adds an item to the top of the stack.
	 * @param item The item which will be added to the top of the stack.
	 */
	public void push(T item) {
		array.add(item);
	}

	/**
	 * Removes the first item from the stack
	 * @return The item that was on the top of the stack.
	 */
	public T pop() {
		/* This gets the size so we don't have to do it twice. */
		int count = array.size();

		/* If the stack is empty return null, note that the Java implementation
		 * of stack throws an Exception instead.
		 */
		if (count == 0) {
			return null;
		}

		/* Remove the last added object (which will have index count - 1) */
		return array.remove(count - 1);
	}
}

Random thought: John Lions wrote a book about the Unix source code, in the seventies, which because it also included some code, was blocked from being published until 1996.

I see only one way out of this mess, we need developers to replace all the closed source parts of Android with free software solutions. This means Android will be free and fully open source. Why stop there though? Lets make Google’s decision into one they will regret! As the open source community is replacing the closed source apps we should build in functionality to allow the phone to work with Google’s competitors. When you first used the G1 you had to sign in using your Google account. What if that same box let you sing in with your Live Id, your Yahoo account or even OpenID? Imagine the Android phone being written in completely open source to work on any operator! It wouldn’t be hard either, most are beginning to provide APIs to their accounts and I’m sure they’d love to help.

Edit: According the the Save Cyanogen Petition application on the market it is impossible to even run the ROMs that Google claim to support without the Google binaries.

Random Thought: Did you know the first Australian computer was built by Trevor Pearcey and Maston Beard in 1947-1951.

Few people don’t realise that subversion has the ability to connect to a remote repository via SSH. Its extremely simple and can give you all the advantages of storing your important files on a server while still having them readily accessible on your desktop. This means that for example you could have your files (and every old version of your files) stored on a RAID device on a server while working with them locally on your desktop.

To set this up its actually rather simple. First you create your repository and perform the initial import of the files. I usually make it in my home directory as follows:

mkdir -p /home/daniel/svn/newproject
svnadmin create /home/daniel/svn/newproject
mkdir -p /tmp/newrepo/{trunk,branches,tags}
svn import /tmp/newrepo file:///home/daniel/svn/newproject -m "Create Initial Structure"
rm -rf /tmp/newproject

These commands are basically what you’d use to create any subversion repository and people familiar with it require no explanation. Most people probably even have is scripted to make it just that much easier. Here comes the fun part though. Next we (on our local machine) check the files out. To checkout subversion repositories over ssh you simply use the following command:

svn checkout svn+ssh://username@servername/home/daniel/svn/newproject/trunk newproject

All going well you will now see a password prompt and upon successful authentication the files will be checked out. This is all that is required and from now on you can simply use the ordinary svn commands.

Random Thought: … and I says to the kernel developer, I says “git this!”

I bought mine two weeks ago and it has completely replaced my Windows Mobile phone to the point where I actually gave it away. The main issues that I have with Windows Mobile was the instability and the difficult to use interface. This new phone was a breath of fresh air. Amazingly when I was testing it out with the seller it received a weeks worth of SMSes indicating that my Windows Mobile phone had stopped accepting them.

I opted for the T-Mobile option. Mainly because I found one cheap on eBay but also because I knew of an exploit to easily get root, flash a new bootloader and install whatever OS I wanted. I knew with almost absolute certainty that I would want to be able to play with root access to the OS. I could have went with the HTC Hero or Magic (the successors to the G1) but I liked the idea of the flip out keyboard way too much.

The G1 is easy to use without a stylus, in fact it won’t work with a stylus as is uses a capacitive touch screen. This means all the applications, the keyboard and the core OS are designed with that in mind. While I could use my old phone with my thumbs many of the controls were impossible to use without perfect precision. Generally all the controls on the Andriod are larger and easier to manipulate, where the Windows Mobile controls are clunky and small.

The Android marketplace is also something that Windows Mobile could certainly have done with. It is an almost perfect image of the iPhone App Store, except that in the culture of open source most of the applications are free. The applications are easier to search for, review and download making the Android Marketplace a much easier to use and more polished tool.

One thing this phone and my last one have in common was the hacker community around them. Both have multiple ROMs available and its relatively easy to flash a new one. I’m currently running the latest stable CyanogenMod (4.0.4) which was extremely easy to flash courtesy of the latest kernel vulnerability and some specially designed tools.

Random Thought: I thought Androids could make breakfast for me.