The way the Gentoo scripts configure sarab (which in turn feeds dar) makes any user-configured keyphrases visible to everybody with shell access. Reproducible: Always Steps to Reproduce: 1. set encryption options including keyphrase in /etc/sarab.conf 2. run a non-trivial backup, so dar is running a few seconds 3. call 'ps --aux' as any user to read confidential keyphrase from shell It is absolutely trivial to fix this problem by e.g. outsourcing the encryption settings to a third file and include this file via sarab's command line option (and dar's respectively): '--batch' A call to 'top' or 'ps' would in that case only show where the password is stored, instead of unveiling the keyphrase directly.
App-backup, the application is in your category, but maintainer-needed. Can you advise on this?
security: It's an old package that mkennedy maintained before he retired. No upstream releases for a couple of years, but from what I'm told, it's still very applicable to the tree. Matsuu maintains DAR, so he might have some insights. axel.privat: could you please attach a patch that implements what you describe?
Created attachment 135665 [details, diff] let dar read encryption options from file sarab.crypt instead of command line
Created attachment 135667 [details] new file /etc/sarab/sarab.crypt containing encryption options
Outsourcing the encryption options to a file that is to be read by dar alters the command line in a way that prevents the keyphrase from beeing exposed. The above patches work for me, hope it helps others, too. Please let me know if the patch cannot be applied (it's the first time I tried to create a patch file) -- I'd like to see the sarab package stay around for a while as it works just as advertised. :)
Created attachment 135668 [details, diff] let dar read encryption options from file sarab.crypt instead of command line fixed comment
...forgot to say that, of course, the file sarab.crypt must have the same restrictive permissions as the file sarab.conf: > chmod 600 sarab.crypt
app-backup, does the patch seem ok? If yes, please provide an updated ebuild.
(In reply to comment #8) > app-backup, does the patch seem ok? If yes, please provide an updated ebuild. > *ping*
(In reply to comment #9) > (In reply to comment #8) > > app-backup, does the patch seem ok? If yes, please provide an updated ebuild. > > > > *ping* > ... timeout :( could someone please apply the patches so that we can move forward? thanks.
0.2.3 is released, and it has included a new password mechanism. From my understanding, it's vulnerable to the same issue. I contacted upstream to work out a solution, because from what I understand, the solution posted here has drawbacks in terms of "testing" backups. I'll report back whenever I have a reply and hopefully bump the package.
0.2.4 has been released. rbu, feel like bumping it?
Right, upstream was very helpful via private mail. I wanted to review the code changes before bumping it though, hopefully soon.
*sarab-0.2.4 (03 Jun 2008) 03 Jun 2008; Robert Buchholz <rbu@gentoo.org> -files/0.2.2-fix-rotation-gentoo.patch, -files/0.2.2-test-with-encryption-gentoo.patch, -files/0.2.2-refname-calculation-gentoo.patch, +files/0.2.4-better-defaults-gentoo.patch, -files/0.2.2-better-defaults-gentoo.patch, files/README.Gentoo, -sarab-0.2.2-r1.ebuild, -sarab-0.2.2-r2.ebuild, +sarab-0.2.4.ebuild: Version bump, fixes security bug #198473 (CVE-2008-2517), DAR encryption passwords were visible to local users via ps. Also introduces support for newer versions of DAR (bug #212048).
