Mercurial > p > roundup > code

comparison doc/security.txt @ 725:2a563dbacd65

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
Initial doc holding collated thoughts on roundup security.
author Richard Jones <richard@users.sourceforge.net>
date Fri, 17 May 2002 00:43:42 +0000
parents
children d341cd0e7689
comparison
equal deleted inserted replaced
724:0085e1d718c4 725:2a563dbacd65
1 ===================
2 Security Mechanisms
3 ===================
4
5 :Version: $Revision: 1.1 $
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 The web interface implements another level of user-interface security,
20 preventing non-admin users from accessing:
21
22 - other user's details pages
23 - listing the base classes (not issues or their user page)
24 - editing base classes
25
26
27 Issues
28 ======
29
30 1. The current implementation is ad-hoc, and not complete for all `use cases`_.
31 2. Currently it is not possible to allow submission of issues through email
32 but restrict those users from accessing the web interface.
33 3. Only one user may perform admin functions.
34 4. There is no verification of users in the mail gateway by any means other
35 than the From address. Support for strong signatures should be added.
36
37
38 Possible approaches
39 ===================
40
41 Security controls in Roundup could be approached in three ways:
42
43 1) at the hyperdb level, with read/write/modify permissions on classes, nodes
44 and node properties for all or specific transitions.
45 2) at the user interface level, with access permissions on CGI interface
46 methods, mailgw methods, roundup-admin methods, and so on.
47 3) at a logical permission level, checked as needed.
48
49 In all cases, the security built into roundup assumes restricted access to the
50 hyperdatabase itself, through Operating System controls such as user or group
51 permissions.
52
53 Hyperdb-level control
54 ---------------------
55
56 Control is implemented at the Class.get, Class.set and Class.create level. All
57 other methods must access nodes through these methods. Since all accesses go
58 through the database, we can implement deny by default.
59
60 Pros:
61
62 - easier to implement as it only affects one module
63 - smaller number of permissions to worry about
64
65 Cons:
66
67 - harder to determine the relationship between user interaction and hyperdb
68 permission.
69 - a lot of work to define
70
71 User-interface control
72 ----------------------
73
74 The user interfaces would have an extra layer between that which
75 parses the request to determine action and the action method. This layer
76 controls access. Since it is possible to require methods be registered
77 with the security mechanisms to be accessed by the user, deny by default
78 is possible.
79
80 Pros:
81
82 - much more obvious at the user level what the controls are
83
84 Cons:
85
86 - much more work to implement
87 - most user interfaces have multiple uses which can't be covered by a
88 single permission
89
90
91 Logical control
92 ---------------
93
94 At each point that requires an action to be performed, the security mechanisms
95 are asked if the current user has permission. There is no possibility to have
96 default of deny in this situation.
97
98 Pros:
99
100 - quite obvious what is going on
101 - is the current system
102
103 Cons:
104
105 - large number of possible permissions that may be defined, possibly
106 mirroring actual user interface controls.
107
108
109
110 Applying controls to users
111 ==========================
112
113 Individual assignment of Permission to User is unwieldy. The concept of a
114 Role, which encompasses several Permissions and may be assigned to many Users,
115 is quite well developed in many projects. Roundup will take this path, and
116 allow the multiple assignment of Roles to Users, and multiple Permissions to
117 Roles. These definitions will be stored in the hyperdb.
118
119
120 Use cases
121 =========
122
123 public
124 end users that can submit bugs, request new features, request support
125 developer
126 developers that can fix bugs, implement new features provide support
127 manager
128 approvers/managers that can approve new features and signoff bug fixes
129 admin
130 administrators that can add users and set user's roles
131 system
132 automated request handlers running various report/escalation scripts
133 privacy
134 issues that are only visible to some users
135
136
137 Discussion
138 ==========
139
140 Date: Thu, 2 May 2002 11:46:56 -0400
141 From: David_Byrne@cisgi.com
142 To: roundup-devel@lists.sourceforge.net
143 I've really appreciated roundup so far. It has been very easy to create my own
144 template that adds functionality for my specific purpose. One area, for my
145 needs, that does not seem to be currently addressed in roundup is roles of
146 users. I have various roles that the users of my instance of roundup can have.
147 I have:
148
149 1) end users that can submit bugs, request new features, request support.
150 2) developers that can fix bugs, implement new features provide support
151 3) approvers/managers that can approve new features and signoff bug fixes
152 4) administrators that can add users and set users roles
153 5) processors - this is isn't totally thought out yet, but for me it would be an
154 automated request handler that would run various production scripts.
155
156 Each of these roles need to have specific functionality within the web client
157 (and possibly the email client -- but I haven't looked at that much yet). An
158 example is that I don't want end users to be able to assign a specific developer
159 to a problem or support issue. I think that some of my functionality can be
160 implemented via the detectors, but I haven't fully researched it yet.
161
162 So far, I have added a new class to the database called role which contains the
163 various roles outlined above. I have added a multilink in the user class to the
164 new role class. I have modified the base code in the cgi client to use the new
165 admin role when checking for admin instead of using the user id. I am working
166 on implementing the role for access to the individual forms and even specific
167 fields on the forms. Has anyone else done this or seen a need to do this?
168
169 I am planning on implementing this as an optional feature - basically the
170 security will be handled in a separate module so that a site could implement the
171 role functionality or exclude it by using the module that fits their needs. My
172 current changes to the admin checks would be pulled out into a separate
173 replaceable module. So if an implementation did not want to use roles, the
174 check would just check the user id to see if it was equal to "admin". In my
175 case, it would check the role of the user to see if it contained the admin role.
176
177 If anyone else is interested in this, I will send the patches in when I am
178 completed with this. If anyone else has worked on this (and hopefully gotten
179 farther than I), please let me know.
180
Roundup Issue Tracker: http://roundup-tracker.org/