POLA - Revision history

Kosik at 07:31, 25 June 2009

Kosik — Thu, 25 Jun 2009 07:31:37 GMT

New page

POLA can stand for principle of least authority or principle of least access.

The principle is to give programs (or any active agent) the minimum [[authority]] which is sufficient for them to perform their intended (by the invoker) task.

The benefit we claim for [[capability|capabilities]] is that they make it practical to apply POLA everywhere, whereas current access-control systems are too coarse, difficult to configure, or don't carry enough information to make proper run-time decisions, such that the only feasible option is to give far too much authority.

Our traditional anti-example is the Solitaire game in Windows. The game only ''needs'' authority to open one window, draw to it, receive events directed at that window, and to read and write a file keeping the high scores; but what it ''gets'' is all the authority bundled into the user account it is running under (just like all other programs run in that account).

The two terms:
* POLA (principle of least authority)
* [http://en.wikipedia.org/wiki/POLP POLP] (principle of least privilege)
give different name to the same idea. We intentionally use the name '''POLA''' instead of the usual '''POLP''' because the second name is distracting. It is not enough to focus on [[Subject, object, operation and permission|permissions]] of the [[Subject, object, operation and permission|subject]]. We must consider its [[authority]].

{{stub}}

Kosik: Added a note concerning distracting term POLP and its relationship with POLA.

Kosik — Thu, 25 Jun 2009 07:30:50 GMT

Added a note concerning distracting term POLP and its relationship with POLA.

←Older revision		Revision as of 07:30, 25 June 2009
Line 6:		Line 6:

	Our traditional anti-example is the Solitaire game in Windows. The game only ''needs'' authority to open one window, draw to it, receive events directed at that window, and to read and write a file keeping the high scores; but what it ''gets'' is all the authority bundled into the user account it is running under (just like all other programs run in that account).		Our traditional anti-example is the Solitaire game in Windows. The game only ''needs'' authority to open one window, draw to it, receive events directed at that window, and to read and write a file keeping the high scores; but what it ''gets'' is all the authority bundled into the user account it is running under (just like all other programs run in that account).
		+
		+	The two terms:
		+	* POLA (principle of least authority)
		+	* [http://en.wikipedia.org/wiki/POLP POLP] (principle of least privilege)
		+	give different name to the same idea. We intentionally use the name '''POLA''' instead of the usual '''POLP''' because the second name is distracting. It is not enough to focus on [[Subject, object, operation and permission\|permissions]] of the subject. We must consider its [[authority]].

	{{stub}}		{{stub}}

Zarutian: corrected number casing of an link

Zarutian — Wed, 08 Oct 2008 01:23:03 GMT

corrected number casing of an link

←Older revision		Revision as of 01:23, 8 October 2008
Line 3:		Line 3:
	The principle is to give programs (or any active agent) the minimum [[authority]] which is sufficient for them to perform their intended (by the invoker) task.		The principle is to give programs (or any active agent) the minimum [[authority]] which is sufficient for them to perform their intended (by the invoker) task.

-	The benefit we claim for [[capabilities]] is that they make it practical to apply POLA everywhere, whereas current access-control systems are too coarse, difficult to configure, or don't carry enough information to make proper run-time decisions, such that the only feasible option is to give far too much authority.	+	The benefit we claim for [[capability\|capabilities]] is that they make it practical to apply POLA everywhere, whereas current access-control systems are too coarse, difficult to configure, or don't carry enough information to make proper run-time decisions, such that the only feasible option is to give far too much authority.

	Our traditional anti-example is the Solitaire game in Windows. The game only ''needs'' authority to open one window, draw to it, receive events directed at that window, and to read and write a file keeping the high scores; but what it ''gets'' is all the authority bundled into the user account it is running under (just like all other programs run in that account).		Our traditional anti-example is the Solitaire game in Windows. The game only ''needs'' authority to open one window, draw to it, receive events directed at that window, and to read and write a file keeping the high scores; but what it ''gets'' is all the authority bundled into the user account it is running under (just like all other programs run in that account).

	{{stub}}		{{stub}}

Kevin Reid: improve/expand

Kevin Reid — Sat, 20 Sep 2008 00:57:55 GMT

improve/expand

←Older revision		Revision as of 00:57, 20 September 2008
Line 1:		Line 1:
	POLA can stand for principle of least authority or principle of least access.		POLA can stand for principle of least authority or principle of least access.
-	~~Basicly it is about not giving programs more authority/access than they need to run to do~~
-	~~their intended job. No more and no less.~~

-	The ~~canocial example~~ is ~~Solarite: an single player game of cards.~~	+	The principle is to give programs (or any active agent) the minimum [[authority]] which is sufficient for them to perform their intended (by the invoker) task.
-	~~The game only needs~~ authority to ~~open one window, draw to it,~~	+
-	~~recieve events directed at that window and read write access to~~	+
-	~~an file keeping the highscores.~~ (~~Optionally read access to image files~~	+
-	~~used as~~ the ~~tabletop, the front faces of the cards and the back face of~~	+
-	~~the cards~~)	+

		+	The benefit we claim for [[capabilities]] is that they make it practical to apply POLA everywhere, whereas current access-control systems are too coarse, difficult to configure, or don't carry enough information to make proper run-time decisions, such that the only feasible option is to give far too much authority.

-	-~~---~~	+	Our traditional anti-example is the Solitaire game in Windows. The game only ''needs'' authority to open one window, draw to it, receive events directed at that window, and to read and write a file keeping the high scores; but what it ''gets'' is all the authority bundled into the user account it is running under (just like all other programs run in that account).

	{{stub}}		{{stub}}

Zarutian: changing references to stub page into reference to template stub

Zarutian — Thu, 18 Sep 2008 22:30:31 GMT

changing references to stub page into reference to template stub

←Older revision		Revision as of 22:30, 18 September 2008
Line 13:		Line 13:
	----		----

-	[[stub]]	+	{{stub}}

Zarutian: /* = */

Zarutian — Wed, 17 Sep 2008 21:39:36 GMT

←Older revision		Revision as of 21:39, 17 September 2008
Line 10:		Line 10:
	the cards)		the cards)

-	~~===~~	+
		+	----
		+
	[[stub]]		[[stub]]

Zarutian: made an stub please expand on and correct any errors

Zarutian — Wed, 17 Sep 2008 21:39:07 GMT

made an stub please expand on and correct any errors

←Older revision		Revision as of 21:39, 17 September 2008
Line 1:		Line 1:
	POLA can stand for principle of least authority or principle of least access.		POLA can stand for principle of least authority or principle of least access.
		+	Basicly it is about not giving programs more authority/access than they need to run to do
		+	their intended job. No more and no less.

-	The ~~principle~~ is ~~to give programs (or any active agent) the minimum [[~~authority~~]] which is sufficient for them~~ to ~~perform their intended~~ (by the ~~invoker~~) ~~task.~~	+	The canocial example is Solarite: an single player game of cards.
		+	The game only needs authority to open one window, draw to it,
		+	recieve events directed at that window and read write access to
		+	an file keeping the highscores. (Optionally read access to image files
		+	used as the tabletop, the front faces of the cards and the back face of
		+	the cards)

-	The benefit we claim for [[capability\|capabilities]] is that they make it practical to apply POLA everywhere, whereas current access-control systems are too coarse, difficult to configure, or don't carry enough information to make proper run-time decisions, such that the only feasible option is to give far too much authority.	+	===
-		+	[[stub]]
-	Our traditional anti-example is the Solitaire game in Windows. The game only ''needs'' authority to open one window, draw to it, receive events directed at that window, and to read and write a file keeping the high scores; but what it ''gets'' is all the authority bundled into the user account it is running under (just like all other programs run in that account).	+
-		+
-	~~The two terms:~~	+
-	* POLA (principle of least authority)	+
-	* [~~http://en.wikipedia.org/wiki/POLP POLP] (principle of least privilege)~~	+
-	~~give different name to the same idea. We intentionally use the name '''POLA''' instead of the usual '''POLP''' because the second name is distracting. It is not enough to focus on~~ [~~[Subject, object, operation and permission\|permissions~~]] ~~of the [[Subject, object, operation and permission\|subject]]. We must consider its [[authority]].~~	+
-		+
-	~~{{stub}}~~	+