Mercurial > p > roundup > code

comparison doc/security.txt @ 3940:251382399e45 1.4.0

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
update
author Richard Jones <richard@users.sourceforge.net>
date Sun, 04 Nov 2007 05:12:07 +0000
parents
children 33a1f03b9de0
comparison
equal deleted inserted replaced
3939:63ab356dfcf9 3940:251382399e45
1 ===================
2 Security Mechanisms
3 ===================
4
5 :Version: $Revision: 1.16 $
6
7 Current situation
8 =================
9
10 Current logical controls:
11
12 ANONYMOUS_ACCESS = 'deny'
13 Deny or allow anonymous access to the web interface
14 ANONYMOUS_REGISTER = 'deny'
15 Deny or allow anonymous users to register through the web interface
16 ANONYMOUS_REGISTER_MAIL = 'deny'
17 Deny or allow anonymous users to register through the mail interface
18
19 Current user interface authentication and controls:
20
21 - command-line tool access controlled with passwords, but no logical controls
22 - CGI access is by username and password and has some logical controls
23 - mailgw access is through identification using sender email address, with
24 limited functionality available
25
26 The web interface implements has specific logical controls,
27 preventing non-admin users from accessing:
28
29 - other user's details pages
30 - listing the base classes (not issues or their user page)
31 - editing base classes
32
33 Issues
34 ======
35
36 1. The current implementation is ad-hoc, and not complete for all `use cases`_.
37 2. Currently it is not possible to allow submission of issues through email
38 but restrict those users from accessing the web interface.
39 3. Only one user may perform admin functions.
40 4. There is no verification of users in the mail gateway by any means other
41 than the From address. Support for strong identification through digital
42 signatures should be added.
43 5. The command-line tool has no logical controls.
44 6. The anonymous control needs revising - there should only be one way to be
45 an anonymous user, not two (currently there is user==None and
46 user=='anonymous').
47
48
49 Possible approaches
50 ===================
51
52 Security controls in Roundup could be approached in three ways:
53
54 1) at the hyperdb level, with read/write/modify permissions on classes, items
55 and item properties for all or specific transitions.
56 2) at the user interface level, with access permissions on CGI interface
57 methods, mailgw methods, roundup-admin methods, and so on.
58 3) at a logical permission level, checked as needed.
59
60 In all cases, the security built into roundup assumes restricted access to the
61 hyperdatabase itself, through Operating System controls such as user or group
62 permissions.
63
64
65 Hyperdb-level control
66 ---------------------
67
68 Control is implemented at the Class.get, Class.set and Class.create level. All
69 other methods must access items through these methods. Since all accesses go
70 through the database, we can implement deny by default.
71
72 Pros:
73
74 - easier to implement as it only affects one module
75 - smaller number of permissions to worry about
76
77 Cons:
78
79 - harder to determine the relationship between user interaction and hyperdb
80 permission.
81 - a lot of work to define
82 - must special-case to handle by-item permissions (editing user details,
83 having private messages)
84
85
86 User-interface control
87 ----------------------
88
89 The user interfaces would have an extra layer between that which
90 parses the request to determine action and the action method. This layer
91 controls access. Since it is possible to require methods be registered
92 with the security mechanisms to be accessed by the user, deny by default
93 is possible.
94
95 Pros:
96
97 - much more obvious at the user level what the controls are
98
99 Cons:
100
101 - much more work to implement
102 - most user interfaces have multiple uses which can't be covered by a
103 single permission
104
105 Logical control
106 ---------------
107
108 At each point that requires an action to be performed, the security mechanisms
109 are asked if the current user has permission. Since code must call the
110 check function to raise a denial, there is no possibility to have automatic
111 default of deny in this situation.
112
113 Pros:
114
115 - quite obvious what is going on
116 - is very similar to the current system
117
118 Cons:
119
120 - large number of possible permissions that may be defined, possibly
121 mirroring actual user interface controls.
122 - access to the hyperdb must be strictly controlled through program code
123 that implements the logical controls.
124
125
126 Action
127 ======
128
129 The CGI interface must be changed to:
130
131 - authenticate over a secure connection
132 - use unique tokens as a result of authentication, rather than pass the user's
133 real credentials (username/password) around for each request (this means
134 sessions and hence a session database)
135 - use the new logical control mechanisms
136
137 - implement the permission module
138 - implement a Role editing interface for users
139 - implement htmltemplate tests on permissions
140 - switch all code over from using config vars for permission checks to using
141 permissions
142 - change all explicit admin user checks for Role checks
143 - include config vars for initial Roles for anonymous web, new web and new
144 email users
145
146 The mail gateway must be changed to:
147
148 - use digital signatures
149 - use the new logical control mechanisms
150
151 - switch all code over from using config vars for permission checks to using
152 permissions
153
154 The command-line tool must be changed to:
155
156 - use the new logical control mechanisms (only allowing write
157 access by admin users, and read-only by everyone else)
158
159
Roundup Issue Tracker: http://roundup-tracker.org/