Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

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 an attachment (id=135665) [details]
let dar read encryption options from file sarab.crypt instead of command line

Created an attachment (id=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 an attachment (id=135668) [details]
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).