Mercurial > p > roundup > code

comparison doc/security-history.txt @ 7091:849e9b2d6926

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