MaxStocker.com   MaxStocker.com    
   
Home About Blog Stuff Contact
 
   
 

May 2008

Facebook busted?
Posted : Sat May 31st

Applet Code Tip
Posted : Thu May 29th

The hidden costs of bad data
Posted : Wed May 28th

Deciphering TCO
Posted : Tue May 27th

Buffers are better
Posted : Thu May 22nd

Feelings nothing more than feelings
Posted : Mon May 19th

A Sense of Scale
Posted : Thu May 15th

More Fun...
Posted : Tue May 13th

No push please
Posted : Sun May 11th

Open wireless network hazards
Posted : Thu May 8th

Caveat emptor
Posted : Wed May 7th

Have Fun
Posted : Tue May 6th

Font Preview Tool
Posted : Fri May 2nd

XML is not a database
Posted : Thu May 1st

Recent Comments

Max in Whose blog is it anyway?
on Mon May 10th

Rob in Whose blog is it anyway?
on Fri May 7th

Anonymous in SEO and the magic beans
on Thu April 8th

Max in SEO and the magic beans
on Thu April 8th

n.o. in SEO and the magic beans
on Thu April 8th

silky in Right way, wrong way
on Fri February 19th

Categories

Technical
69 Entries

Java
23 Entries

Security
18 Entries

Privacy
6 Entries

Database
11 Entries

Internet
58 Entries

Business
31 Entries

Site Updates
19 Entries

Personal
86 Entries

RSS Feed RSS Feed

Tag Cloud

No push please
Posted : Sunday May 11th, 2008

A sure sign of an application that has been poorly thought out from a security perspective is one that allows for "push" ownership.

At this point you are either saying "right on Max" or "what in the heck is he talking about" so for the moment assuming the latter, and if it is the former just bear with me for a second, here is what I am talking about.

In any application with half-way reasonable security users are assigned various permissions to resources and or features. Permissions on resources might allow a user to access or edit a resource and permissions on a feature might alllow a user to use or modify the feature. Obviously permissions are only useful when only certain users can modify them and this is where the concept of "ownership" comes in. The "owner" of a resource or feature is, in short, the person who sets and modified the permissions for other users to access the resource or feature. So given that it's a rather important role.

So who exactly is the owner of a resource or feature? Normally the first owner of any resource would be the person who created the resource in the first place. It kinds of makes sense to have the person who created a resource to be the person to control access to it, at least initially.

But what happens when the ownership needs to change, if, for example the user who was the owner of a resource left the company, or area of the company, went on leave, retired, etc.? In this situation another user "takes" ownership from the first user. How exactly a user may take ownership varies by system and application. In some environments the user relinquishing ownership must enable a certain permission on the resource to allow the ownership to be taken by the second user, in other setups the new owner must be part of a special, Administrators type of group to take ownership from another user.

The key word here though is "take" ownership. Sadly there are systems that rather than letting ownership be taken offer it to be "pushed" instead. In such a system the owner of a given resource or feature can push ownership onto another user.

This type of system is deeply, deeply flawed. Inherent in the concept of ownership is responsibility. If you control access to a resource then you are responsible for access to the resource. The act of "taking" ownership makes the concept of knowing responsibility explict. Allowing ownership to be "pushed" breaks this basic contract and it's entirely possible and most often the case that the owner of a resource may not know that they even are the owner of the resource, they certainly never took any action to get ownership.

Practically speaking the user/group security of an application that allows ownership to be pushed on unsuspecting users is compromised to the point where I think it's justified to say that it's non-existent. If you can't properly assess responsibility then you can never really know who has access to what and when and in the event things go awry you won't know how to fix it, who can fix it and most importantly how to prevent it happening again.

The blithe remark I have often heard given as an excuse for allowing ownership to be pushed is that it makes things "easier for the users". This is rubbish. The concepts of ownership and responsibilities are not foreign concepts to adults and if the security interface to an application is too complex the answer is not to destroy the usefulness of the security model to fix it.

Tags

ownership  push  take 

Categories

Technical  Security 

Comments

Peter - May 12th 2008 6:09 PM
 
How would you describe UNIX-style file ownership? chown allows assignment of ownership to any user:group combination, but (on every Linux box I've owned, at least) can only be run be administrators. (Otherwise there would be a serious security risk because you could create an executable, give it global-execute permissions and suid and then chown it to root:root).


Max - May 12th 2008 6:38 PM
 
I think it's a little more complicated on Unix-y systems because of the concept of "users" who are either the system or an application. Which is a good idea in itself.

Aside from that though the idea as you describe where only the adminstrators are changing ownership is a good one that helps to head off the problem of push ownership as I see it. At the end of the day if you cannot trust your administrators to act responsibly when it comes to assigning permissions and ownership you've got bigger problems on your hands I think.


 
   
  Follow me on Twitter   My Facebook Profile   My LinkedIn Profile   RSS feed of my blog Home   |   About   |   Blog   |   Stuff   |   Contact   |   Privacy Policy  
   
  © 2008 Max Stocker