Create default security policy for Karl

[Chris Rossi]

Security policy for osi is currently in osi.security. Most, if not all, of the code there can probably be moved into karl and regarded as a default security policy. End result would need to be overridable, of course, but should establish reasonable defaults such that Karl can be run without a custom security policy.

[Chris Rossi (chris-archimedeanco)]

This is part of a series of tickets that will involve looking at various "customizations" that have been performed in the osi package for Karl3. Many of these are things that are probably more generally useful than just for osi and the hope is that many of these things can be moved into the karl or karl.content packages as appropriate. The idea here is to pare down to a bare minimum the amount of code that actually lives in the osi package so we can have a better idea of what customizations will be necessary for accomodating other pilots.

For each of these items there will be a judgment call in terms of assigning to one of these categories:

o It is truly a customization and should only ever live in the osi package.

o It is generally useful, should be part of core Karl and can be moved to either karl or karl.content.

o It is generally useful but has some small osi tweak and so should be refactored such that the really useful bits live in karl and osi has only a small tweak, either through configuration or subclassing or some other means.

The hope is most of these will be in the second category.

[Chris Rossi (chris-archimedeanco)]

Hi Tres, is this something you have the time and the inclination to look at?

[Tres Seaver (tseaver)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chris Rossi wrote:

> Hi Tres, is this something you have the time and the inclination to look
> at?
>
> ** Changed in: karl3
> Assignee: Chris Rossi (chris-archimedeanco) => Tres Seaver (tseaver)

I think this needs a great deal of discussion: I doubt that a "default
security policy" is reasonably in scope for a 3.1 release.

For instance, we already know that the three deployment targets for 3.1
are going to have *different* policies: at least one has no notion of
an office at all, and one has expressed grave doubts over the
desirability of the privileged 'KarlStaff' group.

My preference would be to make each target's "customization" package
register its own policy, even if there is significant overlap among some
of the workflow definitions.

Tres.
- --
===================================================================
Tres Seaver [phone] <email address hidden>
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFKQjTt+gerLs4ltQ4RAtELAKCYXvF6yfdk3b0iX4FpCdBpIIsH4gCfU2v8
RZx5cBwiy36tqQfyeDdwbKE=
=exKg
-----END PGP SIGNATURE-----

[Paul Everitt (paul-agendaless)]

On Jun 24, 2009, at 10:15 AM, Tres Seaver wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Chris Rossi wrote:
>
>> Hi Tres, is this something you have the time and the inclination to
>> look
>> at?
>>
>> ** Changed in: karl3
>> Assignee: Chris Rossi (chris-archimedeanco) => Tres Seaver
>> (tseaver)
>
> I think this needs a great deal of discussion: I doubt that a
> "default
> security policy" is reasonably in scope for a 3.1 release.
>
> For instance, we already know that the three deployment targets for
> 3.1
> are going to have *different* policies: at least one has no notion of
> an office at all, and one has expressed grave doubts over the
> desirability of the privileged 'KarlStaff' group.

I'm not sure which that is. I know Oxfam doesn't want "offices" but
they most certainly want staff vs. affiliate. In fact, they
ultimately want the ability to give affiliates less permission (e.g.
moderatorship).

But perhaps this is re-inforcing your point. [wink]

--Paul

>
> My preference would be to make each target's "customization" package
> register its own policy, even if there is significant overlap among
> some
> of the workflow definitions.
>
>
> Tres.
> - --
> ===================================================================
> Tres Seaver [phone] <email address hidden>
> Palladion Software "Excellence by Design" http://palladion.com
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFKQjTt+gerLs4ltQ4RAtELAKCYXvF6yfdk3b0iX4FpCdBpIIsH4gCfU2v8
> RZx5cBwiy36tqQfyeDdwbKE=
> =exKg
> -----END PGP SIGNATURE-----
>
> --
> Create default security policy for Karl
> https://bugs.launchpad.net/bugs/391257
> You received this bug notification because you are subscribed to
> KARL3.
>
> Status in Porting KARL to a new architecture: New
>
> Bug description:
> Security policy for osi is currently in osi.security. Most, if not
> all, of the code there can probably be moved into karl and regarded
> as a default security policy. End result would need to be
> overridable, of course, but should establish reasonable defaults
> such that Karl can be run without a custom security policy.

[Tres Seaver (tseaver)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Paul Everitt wrote:
> On Jun 24, 2009, at 10:15 AM, Tres Seaver wrote:
>
> Chris Rossi wrote:
>
>>>> Hi Tres, is this something you have the time and the inclination to
>>>> look
>>>> at?
>>>>
>>>> ** Changed in: karl3
>>>> Assignee: Chris Rossi (chris-archimedeanco) => Tres Seaver
>>>> (tseaver)
> I think this needs a great deal of discussion: I doubt that a
> "default
> security policy" is reasonably in scope for a 3.1 release.
>
> For instance, we already know that the three deployment targets for
> 3.1
> are going to have *different* policies: at least one has no notion of
> an office at all, and one has expressed grave doubts over the
> desirability of the privileged 'KarlStaff' group.
>
>> I'm not sure which that is. I know Oxfam doesn't want "offices" but
>> they most certainly want staff vs. affiliate. In fact, they
>> ultimately want the ability to give affiliates less permission (e.g.
>> moderatorship).
>
>> But perhaps this is re-inforcing your point. [wink]

Maybe I misunderstood. Anyway, here are a bunch of different policies
related to the 'KarlStaff' group, which could reasonably be varied on a
per-KARL basis:

 - Members of KarlStaff can create communities.

 - Mmebers of KarlStaff have implicit read access to all communities not
   explicitly marked "private".

 - Members of KarlStaff have explicit read access to the /offices and
   /forums areas.

 - Members of KarlStaff can create forums under /forums.

 - Members of KarlStaff can see all profiles.

If I were defining a default security policy for KARL, I wouldn't even
*mention* KarlStaff. I might define another group and allow them to
create communities, but I could imagine requiring KarlAdmin users to
bootstrap communities as a reasonable policy as well.

"Reusable policy" is an oxymoron.

Tres.
- --
===================================================================
Tres Seaver [phone] <email address hidden>
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFKQj0f+gerLs4ltQ4RAt/eAJ9iZJef/wN6bS1hHHCzrUkIKnEuWACdG3za
/o3TR3sE4/i/Gi5m4XDDAUY=
=k4Xe
-----END PGP SIGNATURE-----

[Chris Rossi (chris-archimedeanco)]

Quoth Tres: "Reusable policy" is an oxymoron.