![[tokkee]](http://tokkee.org/images/avatar.png){kind=avatar}
diff --git a/doc/security.txt b/doc/security.txt
index 2d6906ee1ae394dcc64ee485b1faf35903a85d4c..93c64f9e852adddee22018f301bd9dc8b71fc6a7 100644 (file)
--- a/doc/security.txt
+++ b/doc/security.txt
Security Mechanisms
===================
-:Version: $Revision: 1.5 $
+:Version: $Revision: 1.15 $
Current situation
=================
than the From address. Support for strong identification through digital
signatures should be added.
5. The command-line tool has no logical controls.
+6. The anonymous control needs revising - there should only be one way to be
+ an anonymous user, not two (currently there is user==None and
+ user=='anonymous').
Possible approaches
- most user interfaces have multiple uses which can't be covered by a
single permission
-
Logical control
---------------
check function to raise a denial, there is no possibility to have automatic
default of deny in this situation.
-In practice, this is implemented as:
-
-1. there's a mapping of user -> role (in hyperdb)
-2. there's a mapping of role -> permission (in code)
-3. there's a function that's available to all roundup code that can ask
- whether a particular user has a particular permission.
-
Pros:
- quite obvious what is going on
- - is the current system
+ - is very similar to the current system
Cons:
that implements the logical 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.
-
-
-A permission module defines::
-
- class InMemoryImmutableClass(hyperdb.Class):
- ''' Don't allow changes to this class's nodes.
- '''
- def __init__(self, db, classname, **properties):
- ''' Set up an in-memory store for the nodes of this class
- '''
-
- def create(self, **propvalues):
- ''' Create a new node in the in-memory store
- '''
-
- def get(self, nodeid, propname, default=_marker, cache=1):
- ''' Get the node from the in-memory store
- '''
-
- def set(self, *args):
- raise ValueError, "%s are immutable"%self.__class__.__name__
-
- class PermissionClass(InMemoryImmutableClass):
- ''' Include the default attributes:
- - name (String, key)
- - description (String)
- '''
-
- class RoleClass(InMemoryImmutableClass):
- ''' Include the default attributes:
- - name (String, key)
- - description (String)
- - permissions (PermissionClass Multilink)
- '''
-
- def hasPermission(db, userid, permission):
- ''' Look through all the Roles, and hence Permissions, and see if
- "permission" is there
- '''
-
-
-The instance dbinit module then has::
-
- in open():
-
- perm = permission.PermissionClass(db, "permission")
- role = permission.RoleClass(db, "role")
-
- wa = perm.create(name="Web Access",
- description="User may log in through the web")
- wr = perm.create(name="Web Registration",
- description="User may register through the web")
- ma = perm.create(name="Mail Access",
- description="User may log in through email")
- mr = perm.create(name="Mail Registration",
- description="User may register through email")
- aa = perm.create(name="Access Everything",
- description="User may access everthing")
- role.create(name="User", description="A regular user, no privs",
- permissions=[wa, wr, ma, mr])
- role.create(name="Admin", description="An admin user, full privs",
- permissions=[aa])
- ro = role.create(name="No Rego", description="A user who can't register",
- permissions=[wa, ma])
-
- in init():
-
- r = db.getclass('role').lookup('Admin')
- user.create(username="admin", password=Password(adminpw),
- address=instance_config.ADMIN_EMAIL, roles=[r])
-
- # choose your anonymous user access permission here
- #r = db.getclass('role').lookup('No Rego')
- r = db.getclass('role').lookup('User')
- user.create(username="anonymous", roles=[r])
-
-
-Authentication of Users
------------------------
-
-Users must be authenticated correctly for the above controls to work. This is
-not done in the current mail gateway at all. Use of digital signing of
-messages could alleviate this problem.
-
-The exact mechanism of registering the digital signature should be flexible,
-with perhaps a level of trust. Users who supply their signature through their
-first message into the tracker should be at a lower level of trust to those
-who supply their signature to an admin for submission to their user details.
-
-
Action
======
sessions and hence a session database)
- use the new logical control mechanisms
+ - implement the permission module
+ - implement a Role editing interface for users
+ - implement htmltemplate tests on permissions
+ - switch all code over from using config vars for permission checks to using
+ permissions
+ - change all explicit admin user checks for Role checks
+ - include config vars for initial Roles for anonymous web, new web and new
+ email users
+
The mail gateway must be changed to:
- use digital signatures
- use the new logical control mechanisms
-
+
+ - switch all code over from using config vars for permission checks to using
+ permissions
+
The command-line tool must be changed to:
- use the new logical control mechanisms (only allowing write
access by admin users, and read-only by everyone else)
-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
-