Mercurial > p > roundup > code

comparison doc/security-history.txt @ 7109:561c66232347

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