zeitgeist team mailing list archive

[Markus Korn <thekorn@xxxxxx>]

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)

-- 
You received this bug notification because you are a member of Zeitgeist
Framework Team, which is subscribed to Zeitgeist Framework.
https://bugs.launchpad.net/bugs/787868

Title:
  Encryption of database

Status in Zeitgeist Framework:
  New

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.