I'm sorry to say that this isn't as easy as it sounds. It's possible, but there are quite a few complexities involved.
Firstly, which distribution are you using, and which other services do you want to work? This will likely make a big difference to your setup.
Linux systems are not designed to be used like this - if something is sensitive, then it should only be accessible to some specific combination of users or groups, not just disabled for one particular login user. Many daemon processes run as their own user in the expectation that a new user can't access anything that they shouldn't, so if you have sensitive data that's marked as world-readable then this probably doesn't fix that problem.
Depending on your exact requirements, the easiest solution might be to create a virtual machine for that user to log in to. That way you have very secure protection against interfering with the rest of the system. (But you lose the ability to read files in that directory as an existing user, and there will be some CPU overhead).
Step 1 is easy: create a user. Put the user in their own group, and not in the users (or any other) group.
Create a new directory called /home/me/directory_for_this_user and chown it to the new user and group.
At a minimum, a regular user will need to be able to execute some commands (probably a shell of some sort), which means having execute access to that command and any libraries that it uses. So the first step is probably to set up a shell for that user. To keep it simple, I'd compile it a statically linked binary for bash (or ksh or whatever) and install it under /home/me/ (since that's a directory that the user will need read access to). Depending on the shell, you may also need read access to files under /etc/, /tmp/, /usr/tmp, and/or /var/tmp. The shell file itself should have be world readable and executable and not owned by the new user (root is fine) or the new group.
Basically, what you have to do is to clear the "other" (not user/group) read and execute bits on all directories under / apart from /home, and all directories under /home apart from /home/me, and all files in those directories. Some services running on the machine may expect these bits to be set, so take especial care here and test it out first.
All you need to do then is to set the user's home directory to /home/me/directory_for_this_user and their shell to the new login shell.
One further note: there is a seemingly simple solution to this problem known as a chroot jail. While you could put the user in a chroot jail (basically installing a minimal OS under /home/me/directory_for_this_user/), don't rely on this alone: it doesn't actually stop the user from accessing the rest of the system. See
http://www.nic.com/~dave/SecurityAdm...e-3.html#ss3.8. To use a chroot jail, you shouldn't need to compile a shell but just set their login shell to (eg) "sudo chroot /home/me/directory_for_this_user /bin/bash", and configure sudo to allow that user to execute that exact command without a password.
There is another alternative: Some recent Linux systems support Windows-style access control lists (ACLs), but these systems - while being extremely flexible - can get very complicated very quickly, which makes it nearly impossible to secure. I'm not sure if they could provide this kind of access.
Hope that helps, and feel free to ask any more questions because I skipped over a whole lot of detail!
—Robert J Lee