X-Git-Url: https://git.tokkee.org/?a=blobdiff_plain;f=doc%2Fsecurity.txt;h=93c64f9e852adddee22018f301bd9dc8b71fc6a7;hb=3f4c0b8e3c4cd4da683b6ffa27ea58b42f2c564c;hp=2d6906ee1ae394dcc64ee485b1faf35903a85d4c;hpb=4b000bc073069c487d7fd809e00f3b44149af2a6;p=roundup.git diff --git a/doc/security.txt b/doc/security.txt index 2d6906e..93c64f9 100644 --- a/doc/security.txt +++ b/doc/security.txt @@ -2,7 +2,7 @@ Security Mechanisms =================== -:Version: $Revision: 1.5 $ +:Version: $Revision: 1.15 $ Current situation ================= @@ -41,6 +41,9 @@ Issues 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 @@ -99,7 +102,6 @@ Cons: - most user interfaces have multiple uses which can't be covered by a single permission - Logical control --------------- @@ -108,17 +110,10 @@ are asked if the current user has permission. Since code must call the 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: @@ -128,104 +123,6 @@ 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 ====== @@ -237,30 +134,26 @@ The CGI interface must be changed to: 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 -