[Home]OperatingSystemSecurityForCommunitySecurity

MeatballWiki | RecentChanges | Random Page | Indices | Categories
1. Prior contents (as found)
1.1.1. Permissions based on 'Powers' allowed precise 'granularity'.
2. The ProWiki permission system
3. MoinMoin ACLs
This Table Of Contents is not 'comprehensive'. It merely summarizes a trailing comment.

1. Prior contents (as found)

The more we talk about AccessLevels, FunctionalAccess and so on, the more I keep seeing operating security mechanisms adapted to community interaction. Am I the only one?

I would suggest, rather than "This action requires at least such and such access level" to be more like group membership on an OS - arbitrary rights can be given to a group, and enjoyed by all members of that group. Slightly more flexible than a linear scale of increasing access. Of course, I'm a SysAdmin, so I tend to see everything filtered through UNIX and NT permission systems. (Though I think those systems apply quite well here. Just don't imitate the bugs in NT. Please! -- ErikDeBill

Groups in UNIX rarely work very well, mostly because of the limits of 1 group/file and 1 default group per user. I don't know much about groups in NT--on most NT boxes I wind up putting almost all users into "Administrators" because I don't need the protection. --CliffordAdams

NT allows an arbitrary number of users and groups per file. There is no concept of a default group - NTFS by default inherits file permissions from the parent directory (thus making a shared /tmp directory rather impractical). Thus, it's practical to have files which are readable by "Domain Users", allow full control to "Domain Admins", and change control to user "customername" (an ftp account).

This gives a wonderful capacity for complexity - there are many security related aspects to almost every file on the system, so getting a system properly locked down, but not unuseable can be a daunting task. (MS doesn't help, when they allow .dll files to be run as programs, mix normal user programs and administrative tools in the same directory - e.g. "net" and "notepad" in the same dir, and generally ignore the possibility that more than one person may use the system). On the other hand, a Wiki has relatively fewer things to control and should not experience as many problems. A Umask like concept (set for everyone on the wiki) would ensure proper permissions on most things, and let the GodKing/BenevolentDictator tighten individual pages as needed ("new users", and "users" can't directly edit RecentChanges, but "trusted users" can?).

It is possible to convert almost any level-scheme to a group-scheme and vice-versa. Levels become groups like "edit1", "edit2", etc. Groups become levels like TrustedEditor?=1, TrustedIPBan?=0, etc. My current plan is for all "administrative" abilities to be implemented with levels, but be treated mostly like groups (with individual abilities given separately). Other sites may not be as egalitarian, and simply use one or more "admin" levels. --CliffordAdams

I was just worried you'd start doing something like the old BulletinBoardSystems? or SlashCode do: 

if ($user{'level'} >= $action{'level'}) {
    doAction();
}

This makes the implicit assumption that all actions are hierarchical - someone trusted to do foo is also trusted to do bar. There is no way to allow someone to do bar without letting them do foo. You don't seem to be suggesting that. I think it was the "levels" part that had me thinking this... perhaps AccessClasses? might have been less confusing to me.

One reason I like the "level" idea better is that it allows global changes that do not appear to directly target specific users. For example, the current (default) plan is to allow allow level-1 (slightly trusted) users to hide pages. Suppose this was found to be unworkable (too many level-1 attackers maliciously hiding (or unhiding garbage)), and the community decided that requiring level-2 (full membership) should be required. In a level-system, one could raise the required level for "hiding" to 2. Under a group system, one would have to remove all the level-1 users from the "allow hiding" group (possibly even creating a new group). (If there isn't *some* kind of level system, then people will disagree whether they should stay in the "allow hiding" group. Generic groups like "trusted" and "very-trusted" may substitute directly for levels.)

Just to be a nit, Cliff, if one chose to go the way of groups, a different way to go about it would be to structure them like Level0, Level1, . . . . Then each activity would have an access list. Thus, to change the requirements for hiding, you could remove Level1 from the access list for hiding, rather than moving specific individuals from one group to another. Wait a minute. Is this a vacuous statement (i.e., access levels == access levels)? -- anon.

The level system has the advantage of separating the "default" level of access from the individual cases. (The community could raise/lower required levels more easily if they don't need to refer to individuals.) Since a single level may not be enough, exceptions may be granted (or imposed for access reduction). I'm also thinking of automatic time-limits on such exceptions--rather than permanently revoking an individual user's hide-ability, they might lose that ability for a week. Also, administrative power might be given for a limited term (like a few months)--if it is no longer needed (or misused) then it might not be renewed. Administration should be seen as a duty or service to the community, rather than some kind of measurement of value. (Something like "jury duty" (JuryDuty?) in the US is a good example of this kind of civic duty. In some other countries mandatory voting is a similar duty.) --CliffordAdams

Time limits on permissions is something I've wished for in several operating systems. Go for it. It's incredibly convenient to be able to grant special privileges during an emergency and have them automatically go away some time later. I wish that was standard on both NT and UNIX (instead of needing special scripts...) -- ErikDeBill

I hope that most wikis using a level model would use only a few levels, and make it very easy for contributors to reach the highest non-administrative level. For instance, Dave's or Erik's contributions on this page alone would be more than enough for level-2 under my guidelines. If this wiki was under attack, I would likely even deputize both of them with several admin powers. Also, I can't imagine reducing someone's level. If a user misuses a specific ability, that ability might be removed (after one or more warnings). If several abilities are misused repeatedly, then I'd probably suspend their user-ID and let them start over from level-0. (If they misuse several user-IDs, then other technical means may be used to block them.)

As for imitating NT, don't worry. I have enough bugs of my own without imitating anyone else. --CliffordAdams

It isn't surprising that operating security is adaptable to community security, especially multi-user systems, as they are inheritantly social systems. There is a finite resource that needs to be allocated to many competing people. Sounds like a good reason to have a people-oriented security system (as opposed to animal-oriented or natural-disaster-oriented). See also the IncompatibleTimesharingSystem to a big influence for my SoftSecurity campaign. -- SunirShah

Operating Systems have some unique problems, too. Since they can be used in so many ways, controls must be very general. It is also very easy to accidentally use all of the resources - accidental fork bombs or full file systems are fairly routine. Operating Systems need protection from accidents, whereas malice is much more likely to be a problem on a website (spiders may "accidentally" overload a system, but they are actually quite rare). --ErikDeBill

I was just worried you'd start doing something [hierarchical] like: 

if ($user{'level'} >= $action{'level'}) {
    doAction();
}

My intent is for the code to contain calls like: 

if (&AllowUser('action')) {
    doAction();
}

...with all decision making contained in the AllowUser? routine. For the first release, only a few "admin" actions like "BlockIp?" or "DeletePageNow?" will be checked, and AllowUser? might just check to see if the current user is listed in a special "admin" file. This would allow owners and delegated admins to maintain the site remotely.

Later the list of actions and required levels should be stored in a plain text file as a set of number/action pairs. A conservative default file will probably ship with the wiki, but it should be easy to edit for local needs. (I'll probably even allow comments starting with # in the file to make it mostly self-documenting.) If a user has a (current) exception for an action, the required level will be compared against that exception. Otherwise the user's generic level will be compared.

Of course, those with a MetaBaby inclination could make AllowUser? always return 1. It could be interesting until people start using "BlockIpRange?" too freely... --CliffordAdams

Just to add my two cents.. If I where to design this for let say an educational environment then I would take a lot of things from IncompatibleTimesharingSystem, and add a little bit to it. Note: There is no real need for a centralised storage now we all have iPods and Memorykeys, so lets give people access to their files over firewire or usb. This will simplify administration a lot: all files on the system are transient and shared! No more backup problems.

Login should be optional, but unless you do login all the files you make on the centralized storage are owned by "Public Domain" and can be used by anyone. When you login then the files you make are owned by you, however, files you don't access (read or write) for 100 days will become owned by "Public Domain" automatically.

The use of encryption (GnuPG? style) is encouraged and deeply integrated in to the system: all applications should be able to recognize encrypted data and ask for a key. There is no delete option, but files which are not used for n years are automatically "forgotten" (aka deleted), and you can always remove the content of files.

(Sidenote: I would not use a hierarchical structure (a folder that contains multiple files/folders) but I would use a categorical structure: each file can belong to multiply categories (default every file gets a "Owned by $USER" category).

Now I would make one more very big change to the filesystem: No more file locking. When you read a file you will have to give use (get url time), so that you get a copy of the file as it was at that moment. At write you replace the file that was there (there is no merge in the filesystem: this is for the application to take care of). Move, delete and rollback preserve history of the whole storage to a degree (when you're running out of space the least used and oldest history will be lost/recycled. -- Gideon FormerContributor?

1.1.1. Permissions based on 'Powers' allowed precise 'granularity'.

In the early 1970's the Apl 360 file subsystem inpmemented a set of 'permissions', each of which acted as a position in a binary order of magnitude. This allowed exact control of any combination of capabilities, simply by asigning the discrete value that corresponded to the value of the polynomial expansion. (Note: It is not necessary for the values of each term to be Yes or No ( 1 or 0). The mathematics also work when more that two possible values exist (which corresponds to a polynomial expansion in which each position can have a different base value). -- HansWobbe

2. The ProWiki permission system

The ProWiki permissions are contextually (in Context subpages) defined for branches of the page tree, even - if needed - down to the page level. The permissions are inherited and can be redefined in any sub-branch. The configuration options:

for example mean that any user that has admin-status assigned, any user from group ABC (HL and EDB) and TESTER (defined elsewhere) and the individuals HW and SS may edit the page branch. Currently only a few actions (like read and edit) are protected that way, but in principle this is extendable to any action (e. g. upload, spell checking, ...). Of course such group and status commands would not be side by side typically.

There is a syntax to give action permissions to single pages:

and to pages based on wiki words (parts of their name):

so that any page ThisTopic...Article... is automatically protected. The precedence is: page permissions > word permissions > general permissions.

"Context" pages are only admin editable and have an archive setting that stores any single change as a separate page revision.

It's just a start but we are testing and refining step by step and it seems a pragmatic and flexible approach.

Compared to Unix it means that rwx roughly corresponds to (read, write, administrate) but is extendable to any number of action types. A permission may be owned by any number of groups and individual users (instead of one of each). There is no concept of a user default group. There is an additional concept of "permission by page name component = word". -- HelmutLeitner

Could each user have their own workspace (like SocialText), of which they controlled the permissions?

Yes, for example a RealName/WorkSpace?/Context containing:

This would give you complete control to configure and reconfigure this branch. Of course this you also be centrally controlled in a page Context:

-- HelmutLeitner

3. MoinMoin ACLs

MoinMoin uses access control lists to restrict access to pages. Possible access rights are read, write, admin (change acls), delete, revert. ACLs are part of the processing instructions at the top of the page that are not displayed in HTML. Access rights can be granted to individual users or to groups. Groups are stored as bullet lists in wiki pages (*Group). Groups can be member of other groups. ACLs are processed from left to right. The permissions of the first matching user name/group takes effect - later entries are ignored!

There is a acl_default and a acl_before config variable. Right now ACLs are not inherited to sub pages but each page has its own ACL.

For details see MoinMoin:HelpOnAccessControlLists

CategoryWikiTechnology

Discussion

MeatballWiki | RecentChanges | Random Page | Indices | Categories
Edit text of this page | View other revisions
Search: