Directory security

This pages describes a proposed permission system. It hasn't been implemented nor approved so it has nothing to do with the current source code.

Hear the Story (Goals)

Before designing the API, let us settle on what we want from the security system. Here are some goals:

• USER POLICY: Newly registered users should only have basic permissions (ia1 style). We do not credit new users with changing stuff around the website (except for their own profile page) until they prove some respect for our website & content. One user may be promoted to helper (or downgraded to normal) at any time by an administrator. The goal is, of course, to promote most of the active users to helpers but we don't want to expose ourselves to any random registered user.
• WIKI: A helper (a user we trust more than a normal or anonymous user) can edit just about any page throughout the website. She also can create new pages.
• WIKI: Administrators should be able to lock/protect certain pages from editing by any other non-admin user. Some pages needing protection: homepage, archive, contest homepages, vandalized pages, tasks involved in current running contests.
• TASKS: Proposing & testing new tasks should be VERY EASY for a helper. This is a critical feature in order to make ia2 explode. A helper may create new tasks and test them (upload tests, grader and submit solutions) but such testing should not interfere with other users. Contributed tasks should not be visible nor submit-able by any other non-admin user. Note: even other helpers should not see a proposed task until it is published by an administrator. (Remember the goal is to promote most of the active users to helpers. These are important users and we don't want them to see & start solving random invalid tasks). Newly proposed tasks are private.
• USER PROFILE: Users have a personal profile page. This should only be editable by the owner of the page or any other admin user. Even a normal user is allowed to edit his own profile page.
• ATTACHMENTS: Wiki page permissions should expand to attachments. It is only natural to be denied creating or rewriting attachments if you cannot edit the wiki page at all. There is a sorry exception for this: test/grader attachment to tasks. Grader attachments can be read only by administrators and the helper owner of the task. The original helper of the task is not allowed to overwrite or create new grader attachments once the task has been published. This seems a bit odd but consider that attachments are not versioned. Once a task has been contributed to infoarena (and published by an administrator), the helper cannot change her mind and demand the task to be taken down (we'll state that in our terms&conditions); the tasks belongs to infoarena. Wiki page changes can be reverted, users that don't comply can be banned :) but you cannot revert attachments. This also forces administrators to think twice when publishing tasks since they are the ones to do extra work when grader/tests are incorrect and the original helper supplies new versions.

Future Goals

• create private / limited public contests with invitations

Implementation

infoarena uses a simplified security model inspired by UNIX to achieve aforementioned goals.

User Groups

First, we divide users into 4 fixed groups based on their security level. We assert a user belongs to exactly one group at any moment.

+----------------+-------+---------------------------------------------------+
| Security level | Abbr. | Description                                       |
+----------------+-------+---------------------------------------------------+
| normal         | N     | newbies, registered users with no special status  |
| helper         | H     | users we trust with content (see above goals)     |
| administrator  | A     | omnipotent                                        |
| anonymous      | X     | unknown remote user (aka ''the world'')           |
+----------------+-------+---------------------------------------------------+

Resource Directories

infoarena secures a bunch of resources organized in a flat directory structure. We need to organize resources into directories so we can secure operations like create / delete / move which in essence are actions executed onto collections and not onto resources themselves.

Each directory has a R/W bit for every user group. Remember that the R/W bits refer to collections and not to their elements. For example, when creating or deleting a new task you need W permission for the task directory.

+-----------+---------------------------------+-------+-------+-------+-------+
|           |                                 |   N   |   H   |   A   |   X   |
| Directory | What "holds"                    +-------+-------+-------+-------+
|           |                                 | R   W | R   W | R   W | R   W |
+-----------+---------------------------------+-------+-------+-------+-------+
| wiki      | wiki pages but no tasks/rounds  | x   - | x   x | x   x | x   - |
| task      | tasks with their textblocks     | x   - | x   x | x   x | x   - |
| round     | rounds with their textblocks    | x   - | x   - | x   x | x   - |
| attachment| attachments                     | x   - | x   x | x   x | x   - |
| user      | users                           | x   - | x   - | x   x | x   - |
| job       | task submissions                | x   x | x   x | x   x | x   - |
+-----------+---------------------------------+-------+-------+-------+-------+

You can see for example that only helpers and admins can create/delete attachments, anonymous users cannot submit etc.

Textblocks associated to task/rounds/users simply forward the permission query to their resources. When you're editing problema/adunare you're not editing a wiki page but a task.

Resources

Each resource has its own R/W bits for every user group. Additionally, each resource has a owner and a R/W bit for its owner.

It is important to understand the difference between a R/W bit on a directory (which is about the collection itself) and a R/W bit on a resource. For example, if you're editing a task you only need W on that task but no W on the directory. The UI must provide means to edit R/W bits for each resource.

Let's see some examples.

+---+-----------+----------+-------+-------+-------+-------+-------+
|   |           |          |   O   |   N   |   H   |   A   |   X   |
| # | Directory | Resource +-------+-------+-------+-------+-------+
|   |           |          | R   W | R   W | R   W | R   W | R   W |
+---+-----------+----------+-------+-------+-------+-------+-------+
| 1 | task      | adunare  | x   - | x   - | x   x | x   x | x   - |
| 2 | task      | proposal | x   x | -   - | -   - | x   x | -   - |
| 3 | task      | contestx | x   - | x   - | x   - | x   x | x   - |
| 4 | wiki      | home     | x   - | x   - | x   - | x   x | x   - |
+---+-----------+----------+-------+-------+-------+-------+-------+

Legend:
O        owner

(1) a public task: anyone can R but only helpers/admins can W.

(2) a task proposed by a helper: only she and admins can R/W it. For everybody else, her work is invisible.

(3) task included in a current running contest, protected: only admins alter it

(4) wiki page home, protected

Mapping Real Actions to R/W Bits

Every controller is responsible with asking for the right R/W bits. Failing to ask for enough R/W bits leads to security holes.

We construct the Holy Security Reference Table to map real actions to their required R/W bits.

Some Hacks to Make it Work

When checking the directory W bit to create a new job / attachment you need to know some things about the new resource to be created. This could be a simple hook that tells whether you can create a job for this particular task or an attachment with this particular name.

HSRT

Please keep this up to date so we can spot security holes easily!

+----+------------------------------------+-----+-----+-----------------------+
| #  | Action (user story)                | DIR | RES | OTHER                 |
+----+------------------------------------+-----+-----+-----------------------+
|    | view wiki page                     |     | R   |                       |
|    | create wiki page                   | W   |     |                       |
|    | edit wiki page                     |     | RW  |                       |
|    | create attachment                  | W   |     | textblock's W         |
|    | download attachment                |     | R   | textblock's R         |
|    | list attachments                   | R   |     | textblock's R         |
|    | create task                        | RW  |     | textblock's R         |
|    | edit task                          |     | RW  |                       |
|    | view task                          |     | R   |                       |
|    | create round                       | RW  |     |                       |
|    | edit round                         |     | RW  |                       |
|    | view round                         |     | R   |                       |
|    | edit user profile                  |     | RW  |                       |
|    | view user profile                  |     | R   |                       |
|    | submit task solution (job)         | W   |     |                       |
+----+------------------------------------+-----+-----+-----------------------+