~bzr-pqm/bzr/bzr.dev

*****************************
Security aspects of Bazaar-NG
*****************************


* Good security is required.

* Usability is required for good security.

    Being too strict "because it's the secure way" just means that people will
    disable you altogether, or start doing things that they know is wrong,
    because the right way of doing this may be secure, but [..] also very
    inconvenient. 

    -- Linus Torvalds

.. contents:

Requirements
============

David Wheeler gives some good requirements__:
 
    Problem is, the people who develop SCM tools often don't think about what kind of security requirements they need to support. This mini-paper describes briefly the kinds of security requirements an SCM tool should support. 

__ http://www.dwheeler.com/essays/scm-security.html

    confidentiality_
      Are only those who should be able to read information able to do so?

    integrity
      Are only those who should be able to write/change information able to do so? This includes not only limiting access rights for writing, but also protecting against repository corruption.

    availability
      Is the system available to those who need it? (I.E., is it resistant to denial-of-service attacks?)

    identification/authentication
      Does the system safely authenticate its users? If it uses tokens (like passwords), are they protected when stored and while being sent over a network, or are they exposed as cleartext?

    audit
      Are actions recorded?

    non-repudiation
      Can the system "prove" that a certain user/key did an action later?

    self-protection
      Does the system protect itself, and can its own
      data (like timestamps) be trusted?

    trusted paths
      Can the system make sure that its communication with users is
      protected?

Attacker categories
-------------------

* Unprivileged outsiders.

  (Almost always read-only, but people might want to allow them to
  write in some cases, e.g. for wikis.)

* Non-malicious developers with privilege.

* Malicious developers with privilege.

* Attackers who have stolen a privileged developer's identity.


Access control
--------------

Dan Nicolaescu gives these examples of access control:

  - security related code that is still emabargoed, only select few
    are allowed to see it, it is not desirable to release this
    information to the public because a fix is still being worked
    on. It would be nice to be able to have this kind of code under
    the same version control system used for normal development for
    ease of use and easy merging, yet it is crucial to restrict access
    to a branches, files or directories to certain people.

  - feature freeze before a release. It would be good if the release
    manager could disable writing to the release branch, so that the
    last tests are run, and not have someone commit stuff by mistake. 

  - documentation/translation writers don't need write access to the
    whole source code, just to the documentation directories. 

  - For proprietary companies restricting access is even more
    important, for example only some engineers should access the
    latest development version of some code in order to keep some
    trade secrets, etc, etc.

In Bazaar-NG, the basic unit of access control is the branch.  If
people are not supposed to read a branch, or know of its existence,
put it somewhere where they can't see it.  If people are allowed to
read from but not write to a branch then set those permissions.  The
code can later be merged into a public branch if desired with no loss
of function.

We largely rely on lower-level security measures controlling who can
get read or write access to a branch.  If you have a branch that
should be confidential, then put it on an appropriately-secured
machine, with only people in a particular group allowed to read it.

Not having separate repositories is probably a feature here -- unlike
Subversion, no features depend on having branches be in the same
repository.  Each repository can have different group ownership.
(The directories should usually be setgid.)  It also makes it easier
to see just what the access control is; there is only one object that
can meaningfully have an ACL.

The existence of a secret branch can be fairly well hidden from the
world.  When its changes are merged in, all that is visible is the
name, date, and branch name of the commit, not anything about the
location of the source branch.

The documentation case I would handle by having a separate
documentation branch, which could perhaps be checked out into a
subdirectory when it is required.  I think this is fairly common for
larger projects even in CVS.




Confidentiality
---------------

As dwheeler points out, this can be important even for open source
projects, such as when preparing a security patch.
Mechanisms that send email should have an option to encrypt the mail.

I can't think of anywhere encrypted archives would be useful.  If you
want to store it on an encrypted filesystem you can.  If you want to
store encrypted files you can do that too, though that will leak some
information in the metadata and branch structure.


Security in distributed systems
-------------------------------

If I have a branch on my laptop, the software ultimately cannot
prevent me doing anything to that branch -- physical access trumps
software controls.  We can, at most, try to prevent non-malicious
mistakes.

The purpose of the software here is to protect other people, whose
machines I do not control.  In particular, it should be hard for me to
lie to them; the software should detect any false statements.

In particular, these should be prevented:

 * Claiming to be someone else.

 * Attempting to rewrite history.


Revocation
----------

Suppose Alice's code-signing key is stolen by an attacker Charles.
Charles can sign changesets purporting to come from Alice.  

Alice needs to revoke that key; hopefully she has saved a copy of the
key elsewhere and can use that to revoke it.  Failing that she can
mail everyone and ask them to delete it.  This can propagate through
the usual GPG mechanism, which is very nice.

Alice also needs to make a new key and get it trusted.

This revocation does not distinguish between changesets genuinely
signed by Alice in the past, and changesets fraudulently signed by
Charles. 

What can Alice do now?  First of all, she needs to work out what
changesets signed by her key can still be trusted.  One good way to do
this is to check against another branch signed by Bob.  If Bob's key
is safe, we know his copy of Alice's changesets are OK and the full
tree at various points is OK.

Then:

 * Go through her old changesets, check that they're OK -- perhaps
   restore from a trusted backup.  Re-sign those changesets with a new
   key bound to the same email address.  Publish the new signatures
   instead.

   (This seems to indicate it is a good idea to bind signatures to
   changeset by author name/address rather than by key ID.)

 * Roll-up all previous development into a new tree, then sign that.
   This means there is no safe access to the previous individual
   changes, but in some cases it may be OK.

If a key is revoked at a particular time then perhaps we could still
trust commits made before that time.  I don't know if GPG revocations
can support that.


Old keys
--------

Keys also expire, rather than being revoked.  What does this mean?

Ideally we would check that the date when a changeset claims to have
been signed is within the validity period of the key.  This requires
more GPG integration than may at the moment be possible, but in theory
we can do it.

Also need to make sure that commits are in order by date, or at least
reasonably close to being in order (to allow for some clock skew).

One interesting case is when version is committed for which both the
public and private keys have been lost.  This will always be
untrusted, but that should not prevent people continuing to use the
archive if they can accept that.

This suggests that perhaps we should allow for multiple signatures on
a single revision.


Encumbrance attacks
-------------------

A special case where we need to be able to destroy history to avoid a
legal problem.  Allowed as discussed elsewhere: either destroy commits
from the tail backwards, or equivalently branch from a previous
revision and replace with that.

People who saw the original branch can still prove it happened; people
who look in the future will not see any record.  

Either way, probably requires physical branch access.


Multiple signature keys
-----------------------

Should we allow for several signatures on a single changeset?  What
would that mean?  How do we know what signatures are meaningful or
worthwhile?


Forensics
---------

dwheeler:

   [O]nce you find out who did a malicious act, the SCM should make it
   easy to identify all of their actions. In short, if you make it
   easy to catch someone, you increase the attackers' risk... and that
   means the attacker is less likely to do it.

dwheeler asks that the committer's IP address be recorded.  Putting
this in the changeset seems to cause too much of a
privacy/confidentiality problem.  However, an active server might
reasonably record the IPs of all clients.


Non-repudiation
---------------

If a changeset has propagated to Bob, signed by Alice's key, then Bob
can prove that someone possessing Alice's key signed it.  Alice's only
way out is to claim her key was stolen.


Trusted review
--------------

Can be handled by importing onto another branch.  Can have various
levels for "quickly checked", "deeply trusted", etc.

(Is it really necessary to import onto a new branch rather than add
anotations to existing branches?  Copying the whole text seems a bit
redundant.  This might be a nice place for arch-style taggings, where
we just add a reference to another branch.)


Hooks
-----

Automatically running hooks downloaded from someone else is
dangerous.  In particular, the user may not have the chance to check
the hooks are reasonable before they are run.

Conversely, users can subvert client-side hooks.  If we want to run a
check before accepting code onto a shared branch, that must run on the
server.

Enforcing server-side checks gives a good way to run build,
formatting, suspiciousness checks, etc.  This implies that write
access to a repository is through a mediating daemon rather than by
directly writing. 



Signing
-------

We use signing to prove that a particular person (or 'principal',
possibly a robot) committed a particular changeset.

It is the job of external signing software to help work out whether
this is true or not.  This has several parts:

 * Mathematical verification that a signature on a particular 
   changeset header document is correct

 * Determining that the signature corresponds to a particular public
   key

 * Determining that the public key corresponds to the person claimed
   to have authored the changeset (identified by email address.)

The second two are really PKI functions, and somewhat harder than the
first.

The canonical implementation is to use GPG/OpenPGP, but anything will
do.  There are simpler RSA/DSA implementations which assume each user
manually builds a list of trusted keys.

This leaves open the question of which people should be trusted to
provide software on a particular branch or at all.  This is not a very
easy question for software to answer.  We assume that people will know
by other means.  For public code, it may be that all changesets are
re-signed by say samba-team@samba.org.

I think it is fair to distinguish people by an email address, or at
least by $ID@$DOMAIN.  There is no need to have this actually receive
email, so spam need not be a problem.

The signing design is inspired by the very usable security afforded by
OpenSSH: it automatically protects where it can, and allows higher
security to users who want to do some work (by offline verification of
signatures).

Using a signing mechanism other than GPG when key developers already
have GPG and there is a big infrastructure to support it seems
undesirable.  It is true that GPG is quite complex.

The purpose of signing is to protect against unauthorized modification
of archives. 

Bazaar-NG can apply a GPG signature to both patches and manifests.  This
vallows a later proof that the revision and the changeset were produced
by the author they claim to have been written by.

We cannot cryptographically prove that a particular patch was merged
into a branch, because the person doing the merge might have subverted
the patch in the process of merging it.  All we can prove
cryptographically is that the merge committer asserts they took the
patch.

GPGME and PyMe seem to give a reasonable interface for doing this:
there is a function to check a signature, and the return indicates the
signing name, with possible errors including a missing key, etc.


Sign branches, not revisions
''''''''''''''''''''''''''''

Aaron Bentley suggested the interesting idea of signing the mapping of
revisions onto branches, rather than revisions themselves.  For
example a branch could contain just a signed pointer to the most
recent revision. 

(It probably is useful to be able to check signatures on previous
revisions, for example when recovering from an intrusion.)


Protocol attacks
----------------

Both client and server should be resistant to malicious changesets,
network requests, etc.  There's no easy solution.

* Defense in depth.  Check reasonablenes at various points.

* Disallow changesets that try to change files outside of the branch.


Availability
------------

bzr can be configured so as to have no single point of failure to a
denial-of-service attack (or at least nearly none):

* Can have any number of mirrors of a branch.

* If a central server is taken out, developers can continue working
  with state they already have (unbind their branches), and can
  collaborate by email or other means until the server is repaired or
  replaced.

* The origin branch can be on a machine whose location is secret and
  which is not directly publicly accessible.

* Branches can be moved between machines or IP addresses without
  disrupting anything else.

* Branches can be moved around out-of-band, as tarballs over
  bittorrent, etc.

I think the only possible denial of service attacks are those that aim
to shut down the entire network, or block communication with
individual developers, for example by flooding their email address.
But if those people can get connected through some other means, they
can continue.