Dear Maintainer,

   * What led up to the situation?
I am using etckepper with git to keep track of my changes in /etc. After reverting a commit (used commands: revert, reset, commit, checkout) system was working properly and I had a clean repository.
After closing the SSH connection I got alerted about some log entries like this one:

Jul 15 09:04:52 sendai sshd[564]: error: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Jul 15 09:04:52 sendai sshd[564]: error: @         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
Jul 15 09:04:52 sendai sshd[564]: error: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Jul 15 09:04:52 sendai sshd[564]: error: Permissions 0644 for '/etc/ssh/ssh_host_rsa_key' are too open.
Jul 15 09:04:52 sendai sshd[564]: error: It is required that your private key files are NOT accessible by others.
Jul 15 09:04:52 sendai sshd[564]: error: This private key will be ignored.
Jul 15 09:04:52 sendai sshd[564]: error: bad permissions: ignore key: /etc/ssh/ssh_host_rsa_key
Jul 15 09:04:52 sendai sshd[564]: error: Could not load host key: /etc/ssh/ssh_host_rsa_key

Too late. The SSH daemon does not allow incoming connections any longer to fix this.
etckeeper does not keep track of the permissions of /etc/ssh/ssh_host_*_key
Git automatically sets them to 644
On the one hand, SSH keys are world-readable which is a security hole and
on the other hand, SSH does as consquence not allow connections, which is rather unpleasant on servers.
   * What exactly did you do (or not do) that was effective (or
     ineffective)?
   * What was the outcome of this action?
Contacted hosting provider to fix the file permissions.
   * What outcome did you expect instead?
etckeeper/git keeps the permissions of SSH host key files at 600 as it does with other files.

Hi,

Thanks for the bug report. Normally, such bugs should be reported to
security@debian.org with the package maintainer in CC instead of in a
public bug tracker, but let's deal with it now that it's public...

I can confirm the bug: doing a checkout or a reset exposes private files
in `/etc` to all users, bypassing metadata saved in `/etc/.etckeeper`.

A workaround is to setup the `20restore-etckeeper` script as a
post-checkout, post-merge and post-commit hooks:

ln -s /etc/etckeeper/init.d/20restore-etckeeper /etc/.git/hooks/post-checkout
ln -s /etc/etckeeper/init.d/20restore-etckeeper /etc/.git/hooks/post-commit
ln -s /etc/etckeeper/init.d/20restore-etckeeper /etc/.git/hooks/post-merge

Unfortunately, no git hook is ran when you do git reset:

https://stackoverflow.com/questions/17247402/is-there-a-git-hook-that-runs-on-git-reset

So basically, we are screwed: there's no way for etckeeper to fix this
bug for all git commands. This would be a git bug, I believe...

I'm hesitant in doing an upload that "fixes" this because it will give a
false sense of security: some commands will work, others won't. I'd love
to hear from Joey, the upstream author, about how to fix this
better.

The only other thing i could think of that may fix this are smudge
filters, that run whenever code is checked out.

In any case, any of those hacks will make any working tree operations
much slower because the above hook runs *all* the permission changes,
not only the relevant ones...

Any other bright ideas?

A.

Actually, looking back at this, this is not a vulnerability directly
with etckeeper, or at least, nothing that wasn't already clearly
explained in the README. To quote it:

That seems pretty clear to me... So I am downgrading this to a normal
issue and removing the security tag as the security implications of
running etckeeper are clearly stated from the start.

A.

Antoine Beaupré wrote:

Also, the next paragraph points out that permissions won't be restored
when checking out the repository until etkeeper is run, and further on
there are examples of doing checkouts in a mode 700 parent directory to
avoid leaking information.

Smudge filters are an interesting idea, but the current smudge interface
does not provide a way to set file permissions.

No, but it could simply run the init hook to reset all permissions all
the time.

Crude and slow, but would fix the issue here.

A.