doc/security.txt

   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