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:
KMyMoney, instead, is on a roll. The development community is
active and happy, features are being added at an impressive pace,
and that 1.0 release appears to be getting closer. At current
rates, it will be a matter of months, at most, before KMyMoney
surpasses GnuCash in every area which matters to most users - and
keeps on going.
Since then, GnuCash has produced a number of well-received releases and
appears to (still) be the dominant program for personal finance management.
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
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
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
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
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)
On July 16, Brad Spengler disclosed
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)
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
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
Make sock_sendpage() use kernel_sendpage(). kernel_sendpage() does
the proper default case handling for when the socket doesn't have a
native sendpage implementation.
Linus did mention the problem in the 2.6.31-rc6 announcement, though:
There's the NULL pointer fix that was already talked up on
Slashdot, but quite frankly, assuming we got all the "you can't map
things at zero" issues fixed from the last scare, that one
hopefully wasn't quite as bad as it could have been.
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
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
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)
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
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
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:
Location consent: Allow Google's location service to collect
anonymous and aggregate location data. Collection will occur
regardless of whether any applications are active.
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
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
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)
Page editor: Jonathan Corbet
Next page: Security>>