Encryption of database

Reported by Jacob Appelbaum on 2011-05-25
28
This bug affects 5 people
Affects Status Importance Assigned to Milestone
Zeitgeist Framework
In Progress
Wishlist
J.P. Lacerda

Bug Description

I think that Zeitgeist should encrypt databases in ~/.local/share/zeitgeist/* for anti-forensics reasons.

While someone may happen to use an encrypted disk, Zeitgeist may serve as the ultimate accidental spyware to an unsuspecting user. One possible mitigation is to randomly generate a reasonable key, tie it into the login keychain and then use that key with something like http://sqlcipher.net/ rather than straight sqlite.

In theory, a user will never know that this encryption/decryption is happening - no underlying assumptions about the disk need to be made to maintain any security guarantees. This should prevent anyone from learning the contents of the database without also learning the login password. Modern Ubuntu machines disallow non-root ptracing ( https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#ptrace ) and if the gnome keyring is locked, an attacker would have a much harder time grabbing meaningful Zeitgeist data without interacting with the user or bruteforcing the login keychain.

Seif Lotfy (seif) on 2011-05-25
Changed in zeitgeist:
assignee: nobody → Seif Lotfy (seif)

To keep this cross desktop friendly, it makes sense to create a Zeitgeist plugin that interfaces with many different keyring-manager like thing-a-mabobs. Lets call it zeitgeist-keyring-helper.

I imagine that it would make sense to have a flow where when creating a database, Zeitgeist will generate a key, store it with zeitgeist-keyring-helper, fetch the key with zeitgeist-keyring-helper, and finally it will initialize and use the database. All subsequent accesses will simply call the zeitgeist-keyring-helper to fetch the key in a transparent manner.

Seif Lotfy (seif) wrote :

I think the approach is reasonable and maybe the best till now. Instead of people telling us encrypt our DB you actually came up with is well thought through! I would gladly take a stab at it :)

I wonder: What's the attack surface here once the database is unlocked and opened?

It is likely that the attack surface here is very large during execution and the above protection would probably only be useful for data at rest (sqlcipher) and against key recovery attacks that involve ptrace by non-root users (on ubuntu).

An attacker will still be able to become a Zeitgeist client and pull the data out of the database as part of an API call of some sort.

So overall, I think that this limits the attack surface considerably but without a comprehensive API filter of some kind, it's possible that malware on the system (or a forensics person who popped a shell) will still be able to siphon out data.

Seif Lotfy (seif) wrote :

So sqlcipher deals with zeitgeist DB not being able to be copied somewhere else. +1 (data at rest)

Keyring solution takes away the complexity from the user to not have to deal with dencryption of the DB +1

Maybe some way of having a locked API where we need apps to connect to us using the key in the keyring could be a possibility.

An easy way to create the API would be to prevent client connections to Zeitgeist from programs not installed on a system wide basis. Any program running from a temp file system or from the user's home directory is likely to be customized and prompting the user for input seems reasonable. In most other cases, we can assume that the software is authorized - root could simply replace Zeitgeist all together - If root is installing unsafe (spyware) software, no user prompting is going to save them.

The most ghetto of possible methods on Linux is to resort to mucking about in proc:

ls -sla /proc/20963/exe
0 lrwxrwxrwx 1 foo bar 0 2011-05-25 02:29 exe -> /bin/zsh4

It isn't stable to look at argv[0] (/proc/$PID/cmdline) and of course this isn't portable at all.

I guess the source to lsof probably contains the most "cross platform" collection of ways to fetch a process name/path.

Siegfried Gevatter (rainct) wrote :

I don't see the point, applications can still get a copy of the database querying for it over D-Bus. If you're worried about what's on the disk, full home directory encryption is the most logical choice (or moving ~/.local/share/zeitgeist into ~/Private).

Siegfried Gevatter (rainct) wrote :

> An easy way to create the API would be to prevent client connections
> to Zeitgeist from programs not installed on a system wide basis. Any
> program running from a temp file system or from the user's home
> directory is likely to be customized and prompting the user for input
> seems reasonable.

This, OTOH, is something I had thought about. The problem is, how do we know which application is talking to us? We just get it's D-Bus name.

Markus Korn (thekorn) wrote :

I'm with Siegfried when it comes to add an extra encryption layer on top of the db, basically I fail to understand why putting the db in an encrypted filesystem is not good enough.

But what I find interesting is the idea of limiting the ability to access the activity log to system-wide installed clients. And fortunately this is not hard to implement, as we already get the bus_name of the sender as 'sender' argument to all our public methods, and dbus has the GetConnectionUnixProcessID() which returns the process id of the client. All we now have to do is parsing the cmdline entry in proc (let's ignore possible attack vectors for now)

Full disk encryption is not a dependency for Zeitgeist; it's not reasonable to punt on security simply because someone might run their computer in a safe, without a network and without any attackers... :-)

Limiting the access can be done by inspecting the proc entry for /proc/$PID/exe and only if you own the process is it possible for you to dereference the symlink.

Here's some code the shows why parsing /proc/$PID/cmdline isn't a good idea: https://github.com/ioerror/chameleon

If we assume that a user is running the program that is a Zeitgest client, we can check that exe points to something that is owned by root. That should improve things significantly.

Every new Ubuntu user is being tracked by Zeitgeist and if they lose their desktop computer/laptop, they're going to reveal a lot of data that they might never have known was being collected. At least with db encryption the person with the laptop has to mount some kind of attack before they get the rest of the goods.

It's worth noting that Zeitgeist is on by default whereas disk encryption is merely an option. Zeitgeist isn't even aware if disk encryption is in use, so that line of discussion almost seems like a red herring.

After discussing with Seif, I realized that there's a major issue that seems to be unspoken. Zeitgeist is meant to be cross-platform "myware" program - it helps you to use your computer.

There's a problem with the implementation though - some platforms are not really privacy protecting or user friendly by default; they may not all offer disk encryption or real data protection of any kind. So in effect, when Zeitgeist is running, you have no idea if you're safe in certain threat models. This is the flip-side to any myware program: when the data collected falls into the wrong hands, Zeitgeist becomes spyware that is harmful to the user. If Zeitgeist doesn't encrypt the database by default, the answer to "am I secure if my device is lost?" is at best, a maybe and by default, a no.

Seif Lotfy (seif) wrote :

I agree 100% with Jacob that we need to work on these security issues. While some people might find it paranoid, we should try to minimize our attack surface.

AFAIK http://sqlcipher.net/ is cross-platform the only thing we will need to do is package it for Ubuntu. It offers protections on platforms that are hard to otherwise protect. During the generation of a NEW DB we just need to add "PRAGMA key = 'passphrase';" And then we need to copy data from the old into the new DB.

Right now anyone can do anything with our DB and the user may not even know the DB is being created.

Examples:
1) Copy the DB as it is into another physical drive
2) Any process can hook into zeitgeist and push out info

Those have to be fixed...
It won't cost us anything and people will not complain if we do it. The chances of people praising us for respecting their privacy is much bigger. AFAIK MeeGo people had a BIG issue with us being unencrypted. At UDS people told me they deinstalled Zeitgeist because of their fear of their data being exploited.
Now we cant fix both within the next 2 - 3 weeks to a much better state. But we have to start with it now.

I would like to start with the database encryption. I think we can land this as a new feature. And to be honest for that I don't care about backwards compatibility. What are the chances that:
1) People move away from Zeitgeist because it is in a way spyware
2) then people moving away after we encrypt the database because for them it will be backwards incompatible.

I am not going to get into details of the keyring stuff now. But again its a vector that risks exploitation. We will need to tackle this properly. But the sqlite cypher stuff can be done in a matter of a couple of days including packaging (using Siegfried power) :P

I think that the default keying for sqlcipher is sorta weak - so I'd probably suggest using a raw key rather than their password function. Their password function is pretty weak...

J.P. Lacerda (jplacerda) wrote :

First off, thanks to Jacob for taking the time to provide such complete use cases / examples / API suggestions, these are much appreciated! I agree that this is an issue which needs to be tackled. The crux of the matter, as outlined by Jacob, is that Zeitgeist is enabled by default in 11.04, while encryption of /home is optional. As thekorn and RainCT, said, encrypting activity.sqlite isn't the solution to all of our problems, but at least it rules out some attack vectors. I feel like this would be a good start (I'll package sqlcipher tonight).

J.P. Lacerda (jplacerda) wrote :

Here's an update on our recent efforts:

1) RainCT and I have been packaging sqlcipher -- I don't think it should take us much longer to finish (RainCT can probably give a better estimate);
2) I have confirmed (via LD_PRELOAD) that sqlcipher somewhat works with the existing pysqlite bindings, we will need to focus on a non-hacky solution after we have finished the packaging;
3) It is trivial to support keyring integration (this can be done by using the external keyring module, which provides cross-platform support for GnomeKeyring, KDEKWallet, OSXKeychain, and Win32CryptoKeyring);
4) I have already written the code that integrates sqlcipher with Zeitgeist, it's just a matter of testing once packaging is complete.

Regarding the generation of a raw key, I'm currently using the following method:

base64.b64encode(hashlib.sha256(str(random.getrandbits(256))).digest()

Perhaps Jacob could comment on the viability of this method?

Seif Lotfy (seif) on 2011-05-31
Changed in zeitgeist:
assignee: Seif Lotfy (seif) → J.P. Lacerda (jplacerda)
importance: Undecided → Medium
Seif Lotfy (seif) on 2011-06-02
Changed in zeitgeist:
status: New → In Progress
J.P. Lacerda (jplacerda) wrote :

I now have the python bindings working -- all that remains is packaging.

Some comments:

 1) The default ZG integration in Ubuntu 11.04 (and 10.10 netbook edition) logs nothing that can't already be found in recently-used.xbel (except zg also logs when you launch apps (but not what you do with them)). So saying that ZG makes Ubuntu less secure by default is a misunderstanding - and users that have disabled zg has degraded their user experience for no reason.

 2) From an architectural pow I think that all encryption logic should be confined in an extension. This probably require that extensions can provide a factory method of some sorts for the DB connection (which they can not do now). To make this clean we should make sure that we can only have one such factory at a time - or that they can sit on top of each other in some way... Also consider upgrade paths.

 3) I think we should limit our security support to DB encryption since that is a very clearly defined thing. If we have some somewhat-but-not-really-secure heuristics our security profile will just become unclear to ISVs or distros.

Seif Lotfy (seif) wrote :

So what is the status on this.
AFAIK it works and need to be packaged or did I miss something JP?
If its all about packaging then please contact RainCT or didrocks for assitance.
Cheers
Seif

J.P. Lacerda (jplacerda) wrote :

After talking with the maintainer of sqlcipher, I'm now using the v2beta branch, which provides an sqlcipher_export function, making my life much easier. I'm exposing this function to python-sqlcipher (the bindings), and then making use of it within Zeitgeist. Basically, this allows us to attach an unencrypted db to an encrypted db with a simple subroutine call, rather than having to specify the entire schema manually. Someone could start packaging this, I believe that most of the packaging for sqlcipher has been done.

J.P.

Siegfried Gevatter (rainct) wrote :

What's the status of this? I think there hasn't been any activity on this since before the Vala port started.

@jplacerda: Are you still interested in working on it?

Changed in zeitgeist:
importance: Medium → Wishlist

I think I will take over this soon...

On Tue, Apr 10, 2012 at 5:22 PM, Siegfried Gevatter <email address hidden>wrote:

> What's the status of this? I think there hasn't been any activity on
> this since before the Vala port started.
>
> @jplacerda: Are you still interested in working on it?
>
> ** Changed in: zeitgeist
> Importance: Medium => Wishlist
>
> --
> You received this bug notification because you are subscribed to The
> Zeitgeist Project.
> https://bugs.launchpad.net/bugs/787868
>
> Title:
> Encryption of database
>
> Status in Zeitgeist Framework:
> In Progress
>
> Bug description:
> I think that Zeitgeist should encrypt databases in
> ~/.local/share/zeitgeist/* for anti-forensics reasons.
>
> While someone may happen to use an encrypted disk, Zeitgeist may serve
> as the ultimate accidental spyware to an unsuspecting user. One
> possible mitigation is to randomly generate a reasonable key, tie it
> into the login keychain and then use that key with something like
> http://sqlcipher.net/ rather than straight sqlite.
>
> In theory, a user will never know that this encryption/decryption is
> happening - no underlying assumptions about the disk need to be made
> to maintain any security guarantees. This should prevent anyone from
> learning the contents of the database without also learning the login
> password. Modern Ubuntu machines disallow non-root ptracing (
> https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#ptrace )
> and if the gnome keyring is locked, an attacker would have a much
> harder time grabbing meaningful Zeitgeist data without interacting
> with the user or bruteforcing the login keychain.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/zeitgeist/+bug/787868/+subscriptions
>

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers