Security Policy modeled after SELinux

[Vlad K.]

Hello all,


I have an app with relatively complex security/permissions requirements and I decided to build it modeled after SELinux.

The default Pyramid authz policy revolves around checking if a user belongs to a group, or has certain principal, the check of which is facilitated per view (with `permission` argument).

In my app I have several roles and each role can only access some resources, and only perform some actions upon those resources (read, write, delete, ...), and the permission is not static per view, but depends on data retrieved from database according to some identifier given through matchdict.

For example, "regular" users can create new and edit only own content of class X, Y, Z. Users belonging to a "editor" role can view other people's X, Y, Z but can't modify them except some properties thereof (like active/inactive). Perhaps editors can't write their own content, so they would only have `read` permission. Users belonging to a "billing" role can only view billing data of users, create invoices, activate/deactivate profiles, but not view or change their content, etc....



I decided to make a class which I reify as request.permits property (via config.set_request_property()), then do a following check:

@view_config(route_name="some_route", ...):
def some_view(request):
    resource_id = int(request.matchdict["resource_id"])

    resource = DBSession().query(Resource).get(resource_id)
    if resource and not request.permit(resource, read=True):
        raise Forbidden()

    if not resource:
        raise NotFound()

    ...

The permit() method is a __call__ method of the policy class. It does several things:

1. Checks the type of first parameter  (the "tcontext" in SELinux lingo)
2. According to its type (isinstance), delegates check to a private method responsible for that resource class (content classes, menu links, ...)
3. The private method does whatever check required to see if the user (authenticated in the system with some principal like ID, the "scontext" in SELinux lingo) has access to the resource for given action (read, write, delete)

Example checks (which would be policy rules in SELinux):

# request.userauth is also an object created with config.set_request_property()
if resource.owner_id == request.userauth.user_id and (read or write):
    return True
if "required_role" in request.userauth.roles and (read and not write):
    return True

etc... The default, of course, being no permission at all. It can be more DRY if the `permits` callable threw Forbidden() automatically, but I need it in the templates to return True or False which defines parts to be rendered. Alternatively I can supply a `nothrow=True` kwarg to return False instead of raising Forbidden().

This way I maintain the policy in single file, the policy can be "pluggable" if required (instantiate different policy depending on configuration) and it can even be compounded with the view_config's permission argument, and the custom authorization policy factory which implements the proper interface.


Too complicated? Overkill? Anyone doing something similar?

-- 


.oO V Oo.


Work Hard,
Increase Production,
Prevent Accidents,
and
Be Happy!  ;)

[Robert Forkel]

I guess I'm doing something similar. At least as far as having
resource specific permissions. But I've chosen to implement this using
context factories. So the

resource_id = int(request.matchdict["resource_id"])
resource = DBSession().query(Resource).get(resource_id)

if not resource:
raise NotFound()

code which you have in the view is in my case part of the context
factory. Additionally, the context factory attaches a trivial __acl__
attribute to the context (allowing or denying the current user) to
make the standard authorization policy work.

> --
> You received this message because you are subscribed to the Google Groups
> "pylons-discuss" group.
> To post to this group, send email to pylons-...@googlegroups.com.
> To unsubscribe from this group, send email to
> pylons-discus...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/pylons-discuss?hl=en.

[Robert Forkel]

Route Factory seems to be the proper term, see
http://pyramid.readthedocs.org/en/latest/narr/urldispatch.html#route-factories

[Vlad K.]

On 08/31/2012 11:37 AM, Robert Forkel wrote:
> I guess I'm doing something similar. At least as far as having
> resource specific permissions. But I've chosen to implement this using
> context factories.

Thanks for your reply.

That would work except it is limited to checks at routing / view
mapping. The approach I'm having is a completely separate policy class
that can be queried by any part of the code, specifically:

- view config to get general view permission
- view handlers to get permission based on loaded resource (this would
also work well with traversal)
- templates to know which parts to render (menu options, content boxes,
etc...)
- other parts of the code

with the policy neatly defined in single file / class. So when you query
the policy, you basically ask it to:

1. verify action named X (eg. "article.edit")
2. with source context Y (eg. user profile ID and/or user's role(s) )
3. with target context Z (eg. SQLA article model)