From 5de2f2bba891d8ba2dc0dcc93d80022f8ce05b19 Mon Sep 17 00:00:00 2001 From: richard Date: Fri, 17 May 2002 00:43:42 +0000 Subject: [PATCH] Initial doc holding collated thoughts on roundup security. git-svn-id: http://svn.roundup-tracker.org/svnroot/roundup/trunk@738 57a73879-2fb5-44c3-a270-3262357dd7e2 --- doc/security.txt | 180 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 180 insertions(+) create mode 100644 doc/security.txt diff --git a/doc/security.txt b/doc/security.txt new file mode 100644 index 0000000..41e6f14 --- /dev/null +++ b/doc/security.txt @@ -0,0 +1,180 @@ +=================== +Security Mechanisms +=================== + +:Version: $Revision: 1.1 $ + +Current situation +================= + +Current logical controls: + +ANONYMOUS_ACCESS = 'deny' + Deny or allow anonymous access to the web interface +ANONYMOUS_REGISTER = 'deny' + Deny or allow anonymous users to register through the web interface +ANONYMOUS_REGISTER_MAIL = 'deny' + Deny or allow anonymous users to register through the mail interface + +The web interface implements another level of user-interface security, +preventing non-admin users from accessing: + + - other user's details pages + - listing the base classes (not issues or their user page) + - editing base classes + + +Issues +====== + +1. The current implementation is ad-hoc, and not complete for all `use cases`_. +2. Currently it is not possible to allow submission of issues through email + but restrict those users from accessing the web interface. +3. Only one user may perform admin functions. +4. There is no verification of users in the mail gateway by any means other + than the From address. Support for strong signatures should be added. + + +Possible approaches +=================== + +Security controls in Roundup could be approached in three ways: + +1) at the hyperdb level, with read/write/modify permissions on classes, nodes + and node properties for all or specific transitions. +2) at the user interface level, with access permissions on CGI interface + methods, mailgw methods, roundup-admin methods, and so on. +3) at a logical permission level, checked as needed. + +In all cases, the security built into roundup assumes restricted access to the +hyperdatabase itself, through Operating System controls such as user or group +permissions. + +Hyperdb-level control +--------------------- + +Control is implemented at the Class.get, Class.set and Class.create level. All +other methods must access nodes through these methods. Since all accesses go +through the database, we can implement deny by default. + +Pros: + + - easier to implement as it only affects one module + - smaller number of permissions to worry about + +Cons: + + - harder to determine the relationship between user interaction and hyperdb + permission. + - a lot of work to define + +User-interface control +---------------------- + +The user interfaces would have an extra layer between that which +parses the request to determine action and the action method. This layer +controls access. Since it is possible to require methods be registered +with the security mechanisms to be accessed by the user, deny by default +is possible. + +Pros: + + - much more obvious at the user level what the controls are + +Cons: + + - much more work to implement + - most user interfaces have multiple uses which can't be covered by a + single permission + + +Logical control +--------------- + +At each point that requires an action to be performed, the security mechanisms +are asked if the current user has permission. There is no possibility to have +default of deny in this situation. + +Pros: + + - quite obvious what is going on + - is the current system + +Cons: + + - large number of possible permissions that may be defined, possibly + mirroring actual user interface controls. + + + +Applying controls to users +========================== + +Individual assignment of Permission to User is unwieldy. The concept of a +Role, which encompasses several Permissions and may be assigned to many Users, +is quite well developed in many projects. Roundup will take this path, and +allow the multiple assignment of Roles to Users, and multiple Permissions to +Roles. These definitions will be stored in the hyperdb. + + +Use cases +========= + +public + end users that can submit bugs, request new features, request support +developer + developers that can fix bugs, implement new features provide support +manager + approvers/managers that can approve new features and signoff bug fixes +admin + administrators that can add users and set user's roles +system + automated request handlers running various report/escalation scripts +privacy + issues that are only visible to some users + + +Discussion +========== + +Date: Thu, 2 May 2002 11:46:56 -0400 +From: David_Byrne@cisgi.com +To: roundup-devel@lists.sourceforge.net +I've really appreciated roundup so far. It has been very easy to create my own +template that adds functionality for my specific purpose. One area, for my +needs, that does not seem to be currently addressed in roundup is roles of +users. I have various roles that the users of my instance of roundup can have. +I have: + +1) end users that can submit bugs, request new features, request support. +2) developers that can fix bugs, implement new features provide support +3) approvers/managers that can approve new features and signoff bug fixes +4) administrators that can add users and set users roles +5) processors - this is isn't totally thought out yet, but for me it would be an + automated request handler that would run various production scripts. + +Each of these roles need to have specific functionality within the web client +(and possibly the email client -- but I haven't looked at that much yet). An +example is that I don't want end users to be able to assign a specific developer +to a problem or support issue. I think that some of my functionality can be +implemented via the detectors, but I haven't fully researched it yet. + +So far, I have added a new class to the database called role which contains the +various roles outlined above. I have added a multilink in the user class to the +new role class. I have modified the base code in the cgi client to use the new +admin role when checking for admin instead of using the user id. I am working +on implementing the role for access to the individual forms and even specific +fields on the forms. Has anyone else done this or seen a need to do this? + +I am planning on implementing this as an optional feature - basically the +security will be handled in a separate module so that a site could implement the +role functionality or exclude it by using the module that fits their needs. My +current changes to the admin checks would be pulled out into a separate +replaceable module. So if an implementation did not want to use roles, the +check would just check the user id to see if it was equal to "admin". In my +case, it would check the role of the user to see if it contained the admin role. + +If anyone else is interested in this, I will send the patches in when I am +completed with this. If anyone else has worked on this (and hopefully gotten +farther than I), please let me know. + -- 2.30.2