doc/security.txt

   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