Leading items

Coming soon: KMyMoney 1.0

Back in 2005, your editor wrote a review of personal finance tools for Linux, focusing on GnuCash, Grisbi, and KMyMoney. The conclusion at the end of that research was that GnuCash had the strongest feature set, but that KMyMoney looked to surpass it sometime in the near future. Four years later, KMyMoney 0.8 remains the current stable series, but that is about to change; the long-awaited KMyMoney 1.0 release is imminent. So it seems time to revisit this important piece of free software.

In 2005, GnuCash appeared to be at a low point. The port to GNOME 2 still wasn't done, distributors were talking about dropping the package, and developer morale seemed low. But when looking at KMyMoney, your editor saw a different picture:

Since then, GnuCash has produced a number of well-received releases and appears to (still) be the dominant program for personal finance management. Active development continues, with the long-defunct database storage option poised to make a return in GnuCash 2.4. On the KMyMoney side, instead, the 0.8 release that your editor reviewed is still the current major stable release; the 0.8.9 update came out in March, 2008. For whatever reason, things seemed to stall for a long time; if there were a need for more evidence that your editor's predictions deserve ridicule, this would be it.

Behind it all, though, the KMyMoney developers have continued their work. As of this writing, the 1.0 release can be expected almost any time. Your editor pulled a copy from the project's CVS repository to see where things stand; the short answer is that KMyMoney has taken some important steps toward being a full-featured personal finance management program. For many (if not most) users, it should be all they ever need.

Building the tool was relatively straightforward, with only a couple of "./configure; install a missing dependency; repeat" cycles required. One interesting surprise was that KMyMoney remains a KDE 3 application. Work is being done to port the code to KDE 4, but the developers are not making any promises about completion dates; getting the 1.0 release out the door seems to have taken priority. Despite being a KDE 3 application, KMyMoney will run fine in KDE 4 environments.

KMyMoney 0.8 was a reasonably polished application; the 1.0 release continues that tradition. Some of the artwork has been toned down a bit; the windows tend toward a relatively sober blue and grey presentation now. As a general rule, the application's presentation is clean, readable, and usable.

As with previous versions, KMyMoney includes an importer for files in the GnuCash format. It gets the job done, mapping GnuCash entries into the KMyMoney way of doing things without any real trouble. There's no support for the business features of GnuCash - KMyMoney is not looking to be a business bookkeeping application - but most users will never notice.

Saving a file in KMyMoney 1.0 brings a nice surprise: the application has been integrated with GPG to encrypt financial files by default. For a user who already has a GPG key, it all works automatically, with no additional configuration work required at all. More advanced users can configure the application to encrypt for multiple keys or (to protect against disaster) for a special backdoor key controlled by the KMyMoney developers. The program also advertises the ability to save a file to an SQL database. According to the documentation, SQLite, MySQL, and PostgreSQL are all supported, but your editor was only offered SQLite as an option - and it didn't work. The database storage feature looks like something that is expected to mature in future releases.

One of your editor's grumbles with version 0.8 was that transaction entry was relatively hard; it was more mouse- and keyboard-intensive than GnuCash. Version 1.0 has improved things somewhat. If one knows the magic control-insert sequence, it is now possible to enter transactions with no mouse clicks required at all. Annoyingly, check numbers cannot be incremented or decremented from the keyboard; one can only type in the new number. Beyond that, it still seems to require too many tabs, and the single-line GnuCash presentation still seems more natural than the two-column form used by KMyMoney, but things have gotten a lot better.

There is a budgeting and forecasting module built into KMyMoney 1.0. The application can put together a provisional budget based on past transactions, then track how the user is doing against that budget in the future. The forecasting code can extrapolate trends into the future, giving the approximate date when the money runs out and foreclosure proceedings begin. The program was, however, unable to forecast when your editor's long-awaited federal bailout would arrive.

A GnuCash feature totally missing from KMyMoney 0.8 was graphical reports. Version 1.0 fills that gap. The tabular reports available in KMyMoney have always been nicely done; now it's possible to get the information in manager-friendly pie-chart form as well. The value of this kind of plot is debatable at best, but there is a certain eye-candy value to them and some of the other plots are more useful. It is, in any case, a feature checkbox that the project needed to fill.

Some progress has been made with online banking; European users with banks supporting HBCI or OFX will be in luck. Your editor, lacking such a bank, was unable to test out those features. Importing of downloaded bank and credit card data is also now supported; the only working format, though is QIF. The GnuCash importer provides an intermediate window showing the transactions to be imported and providing an opportunity for the user to change what will be done. KMyMoney, instead, just dumps the transactions into the specified account; the user must then go through a mouse-heavy process to classify transactions that the program does not recognize. All of the needed functionality is there, but it's a bit rough around the edges.

In summary, KMyMoney 1.0 is a solid application which now has support for all of the features most personal finance users will need. It appears to be quite stable; your editor was unable to make it misbehave or crash - at least, when not trying to use the database storage feature. The developers behind this tool should feel content as they head toward their 1.0 celebration. Thanks to their work, Linux users have two high-quality personal finance tools to choose from.

Comments (12 posted)

Null pointers, one month later

On July 16, Brad Spengler disclosed an easily-exploitable kernel vulnerability based on getting the kernel to dereference a null pointer. This security hole affected a version of the kernel which had not been widely distributed, so it was a problem for relatively few users, but it highlighted a class of problems which was sure to be seen again. Given that, and given our community's perception of itself as being responsive to security problems, it should be safe to assume that steps were taken to prevent null pointer vulnerabilities from opening up systems in the future. The reality is that some things have truly improved, but that some important vulnerabilities remain.

C programmers normally expect that an attempt to dereference a null (zero) pointer will result in a hardware exception which, in turn, causes the program to crash. This happens not because there is anything special about a pointer containing zero, but because the trick of not mapping valid memory at the bottom of the virtual address space has been known and used for decades. If no valid memory is mapped near address zero, the hardware will trap attempts to access memory in that range; that includes attempts to dereference null pointers. It is a useful setup which minimizes the damage caused by misuse of null pointers.

The only problem is that, in the kernel environment, there is no guarantee that no valid memory is mapped at the bottom of the address space. The default is to not map anything there, but applications can request, via the mmap() system call, that the lowest addresses be made valid. So the null pointer address can be made to point to real memory, and this can happen entirely under the control of user space. User-space addresses remain valid when running in the kernel, so, if the kernel can be made to dereference a null pointer, it will be accessing user-controlled memory. Should the kernel try to jump to a null pointer, it will be running user-controlled code directly. Needless to say, this sequence of events would not be good for the security of the system.

After the July disclosure, it was reasonably evident that more null-pointer vulnerabilities had to exist in the kernel. Such bugs are easy to create; all that is required is a missing initialization. A new function pointer added to a structure will be silently set to null by the compiler in every declaration which does not include an explicit initialization for that pointer. Kernel programmers may be diligent about checking for null pointers, but they are human and will miss an occasional check. At times, these checks have been actively discouraged on the reasoning that dereferencing the pointer would, by virtue of oopsing the kernel, provide the same information as the check. For all of these reasons, one must conclude that there will be other situations in which the kernel can be tricked into dereferencing null pointers.

Given that, it would behoove us all to build our systems in ways which are resistant to null-pointer attacks. The /proc/sys/vm/mmap_min_addr parameter was meant to be the first line of defense here; it specifies the lowest address which can be mapped by unprivileged user-space code. Unfortunately, this protection proved porous. Systems with SELinux running, as it turns out, allowed "unconfined" users to map low memory regardless of the mmap_min_addr setting. For many other systems, it was possible to exploit a problem with pulseaudio to run code with the SVR4 personality, which resulted in a mapped zero page. All told, these problems enabled an attacker to bypass the low-memory limits and exploit null-pointer vulnerabilities.

On August 13, another null pointer vulnerability turned up; this one resulted from the combination of a missing function pointer initialization and a failure to check the pointer before jumping to it. It was an easily exploited hole; demonstration code was duly posted and there have been reports that attack code is already attempting to use this vulnerability. The kernel itself was patched quickly, even if the commit which closed this vulnerability was less than forthcoming about the problem:

Linus did mention the problem in the 2.6.31-rc6 announcement, though:

So, do "we" really have all of those issues fixed? We do not, though some important progress has been made in that direction. Take Fedora as an example: the SELinux policy problem which unconditionally allowed "unconfined" users to map low memory has been fixed; as a result, Fedora systems with SELinux running in the enforcing mode are not vulnerable. But the underlying means by which security modules bypass the mmap_min_addr check has not been fixed. So unpatched Fedora systems with SELinux in permissive mode are vulnerable, even though systems with SELinux disabled entirely are not. Updates for Fedora were released on August 15, two days after the disclosure of the vulnerability. Two days may seem slow for a problem of this nature, but, as it happens, only one distributor - Debian - got an update out more quickly.

Red Hat has not, as of this writing, issued an update for this vulnerability. That is unfortunate because most RHEL systems are vulnerable as the result of a policy choice made by Red Hat. RHEL systems, by default, allow "unconfined" users to map low addresses addresses. Red Hat's Dan Walsh explains: "We are not planning on changing the default in RHEL5, to maintain backwards compatibility." So, because compatibility trumps security, RHEL systems (and those running distributions based on RHEL) remain vulnerable to a trivial local root problem with exploit code easily available and in use. Not good.

As of this writing, no other distributors have fixed this problem (though Mandriva's update showed up just before publication). Given that this vulnerability affects every kernel released since 2001, every distribution will have shipped vulnerable kernels. Even those which do not enable SELinux and which have taken steps to mitigate the other zero-page mapping problems should really be moving quickly to close this hole. Leaving the barn door open may not be a wise course of action, even if one trusts the fence which has been built around the barn.

One also should not forget all of those older systems, including embedded systems like DSL routers, which will be exposed to this vulnerability. This hole could be a boon to people trying to liberate the devices they own, but it could also be an easy way to take control of important systems which have long since been forgotten about. 2.4 kernels, too, are affected by this problem; it is easy to imagine that the bulk of these older systems will never be fixed.

One month ago we got an undeniable warning that this kind of vulnerability was coming. The security of many of our systems has undoubtedly improved over the course of that month. Even so, the latest null pointer vulnerability would appear to have taken some distributors by surprise; important holes have not been closed and updates have, in some cases, been slow in coming. We can - and should - do better than this.

Comments (57 posted)

Devices that phone home

By some accounts, the Palm Pre is a nice device; it is, of course, based on Linux. Joey Hess recently stirred up a bit of a fuss when he dug into his device and determined that it was reporting a surprising amount of personal information back to Palm. It seems that Palm knows where Pre owners are, as determined by the GPS receiver; the device also reports information on application use, program crashes, and more. All of this activity is covered under Palm's posted privacy policy, but it is sure to come as a surprise to many users.

Palm is not alone in this kind of activity. More recent Android phones put up a disconcerting confirmation dialog when asked to calculate location information from the cellular network:

If the user withholds consent, the location service will not function at all. Android devices also upload a great deal of other personal information - the phone book, for example - to Google's servers. Amazon's Linux-based Kindle uses its built-in cellular modem to send back log files, information about what books are on the device, bookmark locations, notes, and more. There is no way to turn this reporting off short of disabling the wireless connection.

One of the key advantages of free software was supposed to be freedom from this kind of surveillance. With control over the software on our systems, we can remove feature which were put there for somebody else's benefit. We don't have to create systems which will report our location, application choices, reading preferences, and more to some remote mothership. When we control our systems, we can ensure that those systems don't sell us out to others.

But the three examples listed above are all Linux-based systems. We may be running free software, but we are not getting all of the benefits that freedom is supposed to bring to us. Just because a system is running free software does not mean that it is your friend.

Ensuring our freedom to control devices like these is part of the motivation behind the anti-DRM provisions added to version 3 of the GNU General Public License. Devices running GPLv3-licensed software must make it possible for users to rebuild and replace that software; said users can, in the process, omit any misfeatures that they feel they can do without. But it must be said: GPLv3 appears to have failed in this regard, so far; vendors of closed devices have generally just chosen to avoid software with that license. Your editor is unaware of a single device which was left open because GPLv3 required it.

In any case, many platforms are sufficiently open to enable other solutions to the worst problems. Joey posted a workaround (delete /usr/bin/contextupload) for Palm devices. Fully-open Android devices are available, and those which are not open by design can generally be liberated after the fact. It also appears to be possible to make significant changes to how Kindle devices work - a subject your editor intends to look into in the near future. There are still benefits to having these systems run Linux, even if they are locked down; we understand well how they work and are well equipped to make changes.

That said, the number of users actually making such changes has got to be quite small. It would seem that, as a general rule, we are little concerned about the loss of our privacy. Perhaps views will change after, as seems inevitable, some company is caught badly abusing data collected in this manner. Or, perhaps, life will replicate John Varley's Steel Beach, where Lunar residents restore full power to their Central Computer even after it tried to kill them all because having access to its services is so convenient. It is often the case that having our information available to others is most convenient.

Regardless of how things go, we can only hope to make informed choices if we know what our devices are actually doing. And we'll only know that if we can see what those devices are up to. Knowing that they run something based on Linux is far from enough. That's why attempts to use laws like the US DMCA to shut down investigation and liberation of devices are so scary. It's bad enough to be unable to run the software we want on our devices; being unable to see what those devices are doing behind our backs is even worse.

Comments (42 posted)