#1666 Issue closed: ReaR 2.3 configuration files world-readable in debian package

Labels: bug, fixed / solved / done

OliverO2 opened issue at 2017-12-29 11:25:

Current debian packaging produces wrong permissions. According to the Makefile (target install-config) they should be 0700 (u=rwx,go=-) for directories /etc/rear and /etc/rear/cert/, and 0600 (u=rw,go=-) for /etc/rear/local.conf. Actual permissions in the debian archive:

$ ar x rear_2.3-0_amd64.deb
$ tar tvf data.tar.xz ./etc
drwxr-xr-x root/root         0 2017-12-20 16:19 ./etc/
drwxr-xr-x root/root         0 2017-12-20 16:19 ./etc/rear/
-rw-r--r-- root/root       534 2017-10-02 15:15 ./etc/rear/local.conf
drwxr-xr-x root/root         0 2017-12-20 16:19 ./etc/rear/cert/

jsmeix commented at 2018-01-03 15:04:

@OliverO2
I know nothing at all about Debian packaging.

I assume you are talking about ReaR packages for Debian as in
http://relax-and-recover.org/download/
i.e. from the OpenSUSE Build Service (and not from elsewhere).

I think matching Debian packaging source files are at
https://build.opensuse.org/package/show/Archiving:Backup:Rear/rear-2.3

OliverO2 commented at 2018-01-03 15:09:

@jsmeix Yes, precisely. I've also built the debian package locally with identical results.

jsmeix commented at 2018-01-03 15:31:

By bind googling I found:
https://unix.stackexchange.com/questions/265462/how-to-change-folder-permissions-during-package-installation
which talks about 'dh_fixperms' that is also mentioned in
https://www.debian.org/doc/manuals/maint-guide/dreq.en.html#rules
and described in
https://manpages.debian.org/jessie/debhelper/dh_fixperms.1.en.html

OliverO2 commented at 2018-01-03 17:13:

Yes, seems like dh_fixperms is the culprit. It contradicts its own (inline) manual page, which omits the fact that the script actually makes everything world readable.

So instead of setting permissions to a sane state (as advertised), dh_fixperms paves the way to open up security holes once users insert secrets into their config files. :frowning_face:

jsmeix commented at 2018-01-04 13:41:

@frediz
because in https://github.com/rear/rear/issues/1163 you wrote

I've packaged Relax-and-Recover as "rear" for Debian

you may have a look here in particular at
https://github.com/rear/rear/issues/1666#issuecomment-355068485
whether or not there is perhaps a general security issue
what file permissions Debian packaging results by default?

frediz commented at 2018-01-08 14:49:

@jsmeix thanks for the notice. I'll check the details for the package in Debian.

frediz commented at 2018-01-26 13:09:

Hi,
the default permissions are the one set by dh_fixperms as shown above, and those are sensible default permissions according to Debian Policy and no sensitive information.
Most of configuration files in packages have no reason not to be read and there would be anyway
readable through the package downloadable by everybody in the Debian packages archive which
wouldn't make sense.
Now, by default, these files don't include anything sensitive, so, I'd say that if some rear user wants to
store some keys, he's also responsible for taking care of the protection of the files in an atomic fashion, that is :

  • have /etc/rear/local.conf be 600 if one stores sensitive information
  • have /etc/rear/cert/* be 600 instead of the whole trees be 700
    I completely understand the idea of forcing those permission which is what I started to implement in the package but by default from what the package provides that is nothing, it's a bit overkill. So I'm still wondering :)
    Maybe rear should fail if sensitive information is stored and no proper permissions is set, as other utilities do in that case, so that for some reason if the permissions gets changed, no disaster occurs.
    What do you think ?

F.

OliverO2 commented at 2018-01-29 21:37:

@frediz Thanks for the explanations. I understand what dh_fixperms is trying to accomplish (default permissions when there is no sensitive information present). The problem is that dh_fixperms's documentation simply does not explain what it actually does to file permissions in /etc/.

You are right that ReaR's default configuration doesn't include sensitive information. But probably one of the more popular configuration changes would be setting SSH_ROOT_PASSWORD with a password hash. It's like adding the first password hash to (the read-protected) /etc/shadow in terms of sensitivity. So I'd argue it's better for ReaR users to be safe than sorry here and install the ReaR configuration files read-protected from the start like PR https://github.com/rear/rear/pull/1674 does.

frediz commented at 2018-02-14 16:02:

Hi @OliverO2 (sorry for the delay, I really need to figure out how to get notification on my mails despite checked).
Yes, I thought about all that and don't want to get into troubles :) .. so I'll commit what I initially did
as asked that is set restrictive permissions and also back propagate this to already installed rear package
into Debian.
Thanks guys,
F.

OliverO2 commented at 2018-02-14 16:06:

@frediz You're welcome. Thanks for your feedback!

[Export of Github issue for rear/rear.]