Bazaar Version Control System

Merge lp:~nmb/bzr/admin-guide-security into lp:bzr

Proposed by Neil Martinsen-Burrell on 2009-12-09
Status: Merged
Approved by: Martin Pool on 2009-12-24
Approved revision: not available
Merged at revision: not available
Proposed branch: lp:~nmb/bzr/admin-guide-security
Merge into: lp:bzr
Prerequisite: lp:~nmb/bzr/admin-guide-structure
Diff against target: 132 lines (+111/-0) 2 files modified
To merge this branch: bzr merge lp:~nmb/bzr/admin-guide-security
Reviewer Review Type Date Requested Status
Martin Pool 2009-12-09 Approve on 2009-12-21
Review via email: mp+15850@code.launchpad.net
To post a comment you must log in.
Neil Martinsen-Burrell (nmb) wrote :

This adds some discussion of authentication and access control to the Administrator's guide. It needs careful review since it makes representations about the security of Bazaar.

Martin Pool (mbp) wrote :

+in each user's ``~/.ssh/authorized_keys`` file, where `<type>` is the type of

just to make it clear I'd add "on the server" before the comma.

This should be mentioned in NEWS.

Otherwise good, thanks!

review: Approve
Max Bowsher (maxb) wrote :

Two thoughts:

1) Is it sensible to even mention the idea of using a single public/private keypair shared amongst all developers? Such a configuration would seem to be so very needlessly insecure that I would not even talk about it.

2) Where a line in authorized keys is mentioned, it is described as `ssh-<type> <key>` - I'm not sure it actually makes it clearer to try to decompose the key into parts. I'd imagine that the majority of users would consider the entire line, from ssh-rsa or ssh-dss onwards to be the key. (Also there's a possibility that some users might still be using v1 numeric keys, though they really shouldn't by now.) Another issue is that, for dsa keys, the 'type' you pass to ssh-keygen is "dsa" but the ID token in authorized_keys is "ssh-dss". Maybe something like:
    command="......" <normal-key-line>
would work?

Martin Pool (mbp) wrote :

2009/12/22 Max Bowsher <email address hidden>:
> Two thoughts:
>
> 1) Is it sensible to even mention the idea of using a single public/private keypair shared amongst all developers? Such a configuration would seem to be so very needlessly insecure that I would not even talk about it.

True.

--
Martin <http://launchpad.net/~mbp/>

lp:~nmb/bzr/admin-guide-security updated on 2009-12-22
4874. By Neil Martinsen-Burrell on 2009-12-22

merge trunk to get NEWS updated

4875. By Neil Martinsen-Burrell on 2009-12-22

address comments from reviews

Neil Martinsen-Burrell (nmb) wrote :

Changed in the branch. Thanks for the comments.

David Strauss (davidstrauss) wrote :

It's possible for the same key to be used for multiple usernames, too, as another workaround to the single-branch restriction.

Preview Diff

1=== modified file 'NEWS'
2--- NEWS 2009-12-21 17:25:06 +0000
3+++ NEWS 2009-12-22 04:58:17 +0000
4@@ -42,6 +42,10 @@
5 Documentation
6 *************
7
8+* There is a System Administrator's Guide in ``doc/en/admin-guide``,
9+ including discussions of installation, relevant plugins, security and
10+ backup.
11+
12 API Changes
13 ***********
14
15
16=== modified file 'doc/en/admin-guide/security.txt'
17--- doc/en/admin-guide/security.txt 2009-12-07 18:12:21 +0000
18+++ doc/en/admin-guide/security.txt 2009-12-22 04:58:17 +0000
19@@ -4,6 +4,113 @@
20 Authentication
21 --------------
22
23+Bazaar's philosophy on authentication is that it is best to reuse existing
24+authentication technologies, rather than trying to reinvent potentially
25+complicated methods for securely identifying users. As such, we describe two
26+such uses of existing software for authentication purposes.
27+
28+Using SSH
29+~~~~~~~~~
30+
31+SSH is a very well tested and featureful technology for authenticating users.
32+For situations where all of the developers have local accounts on the server,
33+it is trivial to provide secure, authenticated ``bzr+ssh://`` access. One
34+concern with this method is that it may not be desirable to grant shell access
35+to developers on the server machine. In this case, Bazaar provides
36+``bzr_ssh_path_limiter``, a script that runs the Bazaar smart server on the
37+server machine at a specified path, and allows no other access.
38+
39+To set it up, specify::
40+
41+ command="/path/to/bzr_ssh_path_limiter <path>" <typical key line>
42+
43+in each user's ``~/.ssh/authorized_keys`` file on the server, where `<path>` is
44+the path to limit access to (and its subdirectories). For more documentation
45+on the syntax of the ``authorized_keys`` file see the documentation of the SSH
46+server. This will only permit Bazaar access to the specified path and no other
47+SSH access for that user.
48+
49+If it isn't desired to give each user an account on the server, multiple
50+private/public key pairs can be included under one single SSH account (say
51+sshuser) in the ``~sshuser/.ssh/authorized_keys`` file and then each developer
52+can be given their own private key. They can then use
53+``bzr+ssh://sshuser@server.example.com/`` URLs to access the server.
54+
55+Using HTTP authentication methods
56+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
57+
58 Access Control
59 --------------
60
61+Many projects need fine-grained access control on who may read and write to
62+which branches. Incorporating these controls into OS-level user accounts
63+using groups and filesystem permissions can be difficult or even not permitted
64+in some instances. Bazaar provides a script called ``bzr_access`` that can be
65+used to provide access control based on usernames, with authentication
66+performed by SSH. To do so, we need to set up private-key authentication in
67+SSH. This can be done using a single SSH user on the server, or one account
68+per user. The idea is to use the SSH's ``authorized_keys`` file to specify
69+the ``bzr_access`` script as the only command that can be run by a user
70+identified by a particular key pair.
71+
72+First, you will need to generate a private/public key pair for each user who
73+will be accessing the repository. The private key should be distributed to
74+the user and the public key will be needed on the server to identify the user.
75+On the server, in the SSH user's ``~/.ssh/authorized_keys`` file, use the
76+following line for each repository user and the corresponding public key::
77+
78+ command="/path/to/bzr_access /path/to/bzr /path/to/repository <username>",no- port-forwarding,no-X11-forwarding,no-agent-forwarding ssh-<type> <key>
79+
80+where `<key>` is the (possibly very long) public key, `<type>` is the type of
81+SSH key and `<username>` is the username to associate with that public key.
82+
83+The ``bzr_access`` script obtains its configuration information from the file
84+``/path/to/repository/bzr_access.conf``. This file should not be placed under
85+version control in a branch located at ``/path/to/repository`` since that
86+would allow anyone with access to the repository to change the access control
87+rules. The ``bzr_access.conf`` file is in a simple INI-style format with
88+sections defined by ``[groups]`` and ``[/]``. The options in the ``[groups]``
89+section are the names of groups and the values of those options should be the
90+usernames in that group. Inside the ``[/]`` section, the options are
91+usernames or group names (prefixed with ``@``) and the values are either
92+``rw``, ``r`` or nothing, representing read-write access, read-only access or
93+no access at all. A sample of ``bzr_access.conf`` could be::
94+
95+ [groups]
96+ admins = alpha
97+ devels = beta, gamma, delta
98+
99+ [/]
100+ @admins = rw
101+ @devels = r
102+ upsilon =
103+
104+where the user whose key is associated with `alpha` would have read-write
105+access, the users `beta`, `gamma` and `delta` would have read-only access and
106+user `upsilon` would not be able to access any branches under
107+``/path/to/repository``.
108+
109+Additional Considerations with ``bzr_access``
110+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
111+
112+As currently written, ``bzr_access`` only allows each public key to be
113+associated with a single repository location. This means that if developers
114+need to access two or more different repositories, then each developer will
115+need to have two or more private keys for SSH and be able to select between
116+them (see ``man ssh`` for more information on configuring multiple private
117+keys).
118+
119+Also, each repository can only have a single configuration file, with access
120+configured for all branches in the repository. This means that if different
121+access rules are needed for different projects, then those projects must be in
122+different repositories. This then necessitates the use of multiple private
123+keys as just described.
124+
125+Finally, as noted above under `Using SSH`_ all of the public keys may be
126+included in the ``authorized_keys`` file of a single user on the server. It
127+is also possible to use a single private/public key pair for all of the
128+developers, but this only allows a single username for access control to the
129+repository (since the username is associated with the public key in
130+``authorized_keys``. While this is certainly possible it seems to defeat the
131+purpose of fine-grained access control, although it does provide the same
132+limited SSH access as that described above.