← Back to branch summary

~svn/ubuntu/raring/subversion/ppa

« back to all changes in this revision

Viewing changes to notes/assurance.txt

  • Committer: Bazaar Package Importer
  • Author(s): Adam Conrad
  • Date: 2005-12-05 01:26:14 UTC
  • mfrom: (1.1.2 upstream)
  • Revision ID: james.westby@ubuntu.com-20051205012614-qom4xfypgtsqc2xq
Tags: 1.2.3dfsg1-3ubuntu1
Merge with the final Debian release of 1.2.3dfsg1-3, bringing in
fixes to the clean target, better documentation of the libdb4.3
upgrade and build fixes to work with swig1.3_1.3.27.

Show diffs side-by-side

added added

removed removed

Lines of Context:
notes/assurance.txt
 
1
From: Alex Holst <a@area51.dk>
 
2
Sent: 18 April 2002 03:49
 
3
To: dev@subversion.tigris.org
 
4
Subject:  Subversion and assurance.
 
5
 
 
6
 
 
7
Hi. I've been bribed with bananas again. This time the guilty party is
 
8
gstein who requested that I post a note with my thoughts about security
 
9
and assurance, and what steps can be taken to reduce the possible number
 
10
of security flaws in subversion 1.0.
 
11
 
 
12
First, a brief introduction: When people ask you, as a developer, about
 
13
security in Subversion, you might say Subversion is secure. Subversion
 
14
has access control, it supports SSL, committers need no system accounts,
 
15
and other nice things. These are _security_ features, not nessesarily
 
16
_secure_ features.
 
17
 
 
18
You may have access control, but what if the code implementing this
 
19
access control was written poorly, and contains a buffer overflow?  2
 
20
hours ago you worried about who could read or write to a document in
 
21
your repository. Now you discover that an attacker can execute arbitary
 
22
code as the userid your service is running as. This is not ideal. 
 
23
 
 
24
Hence, we distinquish between "security features" and assurance. Brian
 
25
Snow, a technical director at the NSA, defines assurance as follows:
 
26
 
 
27
        "Confidence-building activities that demonstrate that a system
 
28
        possesses the desired properties and only these properties and
 
29
        that functions are implemented correctly. Assurance can be
 
30
        provided through a structured design process, documentation, and
 
31
        testing."
 
32
 
 
33
Assurance is what protects the user in the case of misuse or when faced
 
34
with malice. Today, cars come with safety functions such as seatbelts,
 
35
ABS breaks, airbags, etc, all of which means that you have a very good
 
36
chance of walking away from accidents. This was not so 50 years ago. I
 
37
strongly recommend listening to Brian Snow's full talk on assurance,
 
38
which is available as a RealPlayer stream from Blackhat.com:
 
39
 
 
40
<http://media.blackhat.com:5554/ramgen/blackhat/bh-usa-00/audio/bh-usa-00-brian-snow-audio.rm>
 
41
 
 
42
The two most important steps that Subversion can take are:
 
43
 
 
44
        Establish secure coding guidelines that are communicated to all
 
45
        developers and enforced by the project leads. 
 
46
 
 
47
        Improve the documentation: A diagram much like qmail's Big
 
48
        Picture which shows how code and data flows within the program.
 
49
        It allows for fast identification of security boundaries.
 
50
 
 
51
These steps will enable greatly improved looks into the Subversion code
 
52
for someone who has not spent the last few months getting familiar with
 
53
the Subversion code.
 
54
 
 
55
Additional steps include:
 
56
 
 
57
       Establish a QA section on the website containing documentation
 
58
       about the tests that are run against Subversion. 
 
59
 
 
60
       Document how new tests for both server and client can be written
 
61
       and encourage users who are in need of assurance to participate
 
62
       in the QA process. The tests against the server should
 
63
       specifically include things like attempting to break ACLs,
 
64
       attempt to issue legal commands in an inproper order, use very
 
65
       long strings for filenames and arguments, etc.
 
66
 
 
67
       The more you document, the more likely it is that someone with
 
68
       the knowledge to spot problems will take a look at what you have
 
69
       done.
 
70
 
 
71
Websites that help:
 
72
 
 
73
        "Secure Programming for Linux and UNIX" by David Wheeler
 
74
        http://www.dwheeler.com/secure-programs/
 
75
 
 
76
        Software Quality Assurance: Documentation and Review
 
77
        http://hissa.ncsl.nist.gov/publications/nistir4909/
 
78
 
 
79
Books that help:
 
80
 
 
81
        "Safer C" by Les Hatton
 
82
        "Solid Software" by Hatton, Howell & Pfleeger
 
83
        "Building Secure Software" by Viega & McGraw
 
84
        "Writing Secure Code" by Howard & LeBlanc
 
85
        "Writing Solid Software" by Maguire
 
86
 
 
87
 
 
88
I'll be delighted to answer any questions. Thanks for your time.
 
89
 
 
90
--
 
91
I prefer the dark of the night, after midnight and before four-thirty,
 
92
when it's more bare, more hollow.                  http://a.area51.dk/