chrishowie.com

Over Christmas break I took a test my mom wanted me to — one based on finding out what types of things you’re good at, not your personality. I came out the strongest in “Ideation” which is defined by the book as the creation of new ideas. Looking back on my life I can see this coming out a lot. And I do mean a lot. I’m great at coming up with new ideas, but once I’ve sufficiently explored one to my satisfaction I put it aside. So you are probably going to see a lot of new projects here with little or no closure. Eventually the source code to all of them will be released under the GPL or some other open-source license. It’s my hope that if one of my ideas generates enough interest that it will be taken on by someone else to be developed into a mature project.

Just a few thoughts. On to the main entry, which is another — surprise — idea!

I wrote a while ago about an idea to jail a Linux process, and a few nights ago I finally realized how I would implement it: D-Bus. A security manager installs itself in a well-known location on the session bus, and programs that know about it use it to request authorization before performing actions. I’m calling the D-Bus specification “Fuzz” for now.

The screenshot to the right is a proof-of-concept implementation of Fuzz, using C# for the manager and a C library preloaded into Iceweasel as a client. This is a live screenshot, not a mock-up — the system works, right now!

So I guess we’ll see how long before I tire of this project. Hopefully not before I have an implementation that works for most needs.

I’ve been pondering a project for about a year now, and I may be ready to finally start coding the beast. The basic idea is you run a process in a jail where it’s completely isolated from the system, except where you let it interact.

The interface is of course through syscalls like open() and connect(). The jail would let you set up a sort of ACL per-process of what syscalls it can make and which it can’t. Think ZoneAlarm, only we’re talking everything, not just network access. But that’s not the real kicker.

This all happens in userspace, and doesn’t require root access.

My idea is to code a preload library that captures all of the important system calls, like open(), connect(), bind(), etc. Some daemon will run on the user’s desktop, and every system call will be sent over a socket to that daemon. Upon receiving the call, the daemon will look in its access tables and send back a message to “proceed” or “fail with this errno.” The daemon may even ask the user in realtime if the call should succeed.

I started coding a Gtk# frontend but stopped after realizing that the network protocol for this baby is going to suck.

Even more challenging will be keeping the process completely jailed. All a process needs to do is unset LD_PRELOAD and spawn another copy of itself and it’s home free. So I’ll need to capture things like setenv() and look for other mechanisms for setting LD_PRELOAD for new processes and make sure that the library remains in that variable and in the front. In short, finding loopholes around it will be relatively simple. Some harmless program may even clobber LD_PRELOAD to perform some similar trick. So that will be another fun aspect of this project.

Perhaps more challenging would be allowing the daemon to alter the call arguments. While powerful, there is simply no good way to represent a void* over a socket.

But if it works… think about it. Your desktop environment could be started with this library preloaded, and then every process started from the desktop could be controlled.

The applications of this go far beyond security. You could deny your web browser access to your sound card to suppress those cute little songs and noises some sites like to play. You could deny all processes access to some directory unless you authenticate to the daemon. (Not exactly real security, but a fine deterrent against unskilled relatives.)

But we’ll see what happens…

You’ve all seen the ads.

“Hi, I’m a Mac.” “And I’m a PC.”

The old-fashioned PC winds up crashing or freezing, leaving the hip, cool Mac standing there looking pleased with himself.

Terminology aside, (it’s “Windows PC” — there are lots of PC OSes) Apple is ignoring what is fast becoming a major competitor: Linux.

I haven’t seen an Apple ad that even goes so far as to mention Linux. Why? Because they can’t compete. Think I’m kidding? What are all the things Apple hypes?

OS X has a pretty slick user interface. Linux has a cooler one.

OS X is easy to use. So is GNOME.

OS X is stable and doesn’t get viruses. Neither does Linux.

Hardware just works on a Mac. A good share does on Linux too. GNOME even mounts removable media that I plug in, just like OS X does.

Oh, and Linux is free. Including all of the software the average desktop user needs.

And that’s why Apple ignores Linux. If they brought it up, people would get curious about it, look into it, then wonder why they forked over three grand to Apple when they could have installed Linux on the box that they already have. It’s the same reason why companies that demo their audio codec against competitors’ never include Ogg Vorbis: because it’s better than theirs, and it’s free to boot.

One of the things I do miss about Windows is the abundance of universal trainers for it. If you don’t know what a trainer is, it’s a program that writes over the memory of another process, typically a game, to confuse the program into doing something it wouldn’t normally do. Trainers are often used to get infinite lives/money/ammo in games. However, they must know where in memory these variables are being stored.

A universal trainer is the most generic trainer: it allows the user to search a process’ memory space for a certain value, and further refine the search until the variable’s location in memory is isolated. Then the user may modify that memory to change that variable while the program is running.

Kcheat is the only similar program I’ve seen for Linux. Unfortunately, it requires KDE 1… which nobody is going to install just to use this program.

Well, Wednesday I decided it might be cool to design a new one. So I did, using portions of Kcheat (mainly the lower level stuff). It’s implemented in C# with Gtk# as the UI, and a small C library to take care of the nasty work. As of last night it’s almost done — already! It can search the memory of a process for six different data types (signed/unsigned 8/16/32-bit integers) and allow their contents to be tweaked. It’s a little unstable as I haven’t done any exception handling yet (except where necessary) but the stable release will be pretty slick. The UI is uncluttered and simple, though demand may see the addition of new features.

The only drawback is that the project is generally pointless: most Linux games that people care about are either network games, which prevent clients from tampering with the data on the server, and the others are open source anyway, so you can just comment out the “if (lives == 0)” line and recompile.

On the other hand, this is easier than recompiling, if a bit hackish.