Protection matrixes in Minix - Revision history

Kosik: /* A trivial denial of service (DoS) attack */

Kosik — Fri, 03 Jul 2009 07:57:38 GMT

A trivial denial of service (DoS) attack

New page

This page documents some of the concrete examples of the [[protection matrix]] concept. In this case, from the Minix world. We first describe lightly describe the structure of the Minix operating system and then we list various different protection matrixes that define certain security policies.

== Minix structure ==

[http://www.minix3.org Minix3] operating system provides classical UNIX-like environment. It provides usual UNIX system calls (fork, exec, exit, kill, open, read, write, etc.) From this point of view, we would have no reason it to prefer it over, say, Linux or FreeBSD.

The goal of the Minix project is to improve the internal quality of the operating system implementation. Why and how is it done is described in the [http://www.amazon.com/Operating-Systems-Implementation-Prentice-Software/dp/0131429388/ref=sr_1_14?ie=UTF8&s=books&qid=1245137182&sr=8-14 Minix book].

The following figure captures the structure of the Minix operating system:

[[Image:Minix-structure.png]]

Processes in Layer 1 run in the kernel space. Processes in Layers 2, 3 and 4 run in the ''user space''. Ordinary user space processes run in Layer 4. Processes that together actually implement the UNIX-like services run in Layers 1, 2 and 3.

'''Layer 1''' contains:
* the '''KERNEL''' task (it implements the scheduler, it provides the inter-process communications primitives used by other processes, it is hooked to IRQs, it enforces security policies defined by protection matrices described below, etc)
* the '''SYSTEM''' task provides various services to user space processes from layers 2 and 3 that must be performed in the kernel space (I/O operations and such). In Minix terminology, they are called "kernel calls".
* the '''CLOCK''' task is actually a device driver of the PIT (Programmable Interface Timer chip) that would be hard to move to user space so it runs in the kernel space.
In Minix terminology, processes running in '''Layer 1''' are called '''tasks'''.

'''Layer 2''' contains various processes that behave as device drivers ('''DRV''').

'''Layer 3''' contains various higher level subsystems:
* The process manager ('''PM''') implements most of the UNIX services that are related to processes.
* The file system ('''FS''') implements most of the UNIX services that are related to files.
* The reincarnation server ('''RS''') periodically checks whether particular device drivers run. It restarts those that crashed (e.g. due to a segmentation fault).
* The data server ('''DS''') can be used by device drivers to store their internal state so that restart of the device driver does not disrupt the on-going services provided by this driver.
* etc.

Ordinary processes run in '''Layer 4'''.

The following section describe various examples of protection matrixes present internally within Minix. Each of them is enforced by the '''KERNEL''' task. Subjects can try to perform any operation on any objects, but the '''KERNEL''' task subsequently checks whether a given subject has permission to perform a chosen operation. Minix is thus an [[ambient authority system]].

== Protection matrix that defines which processes can use which IPC mechanisms ==

The '''KERNEL''' task provides five different IPC primitives:
* send
* receive
* sendrec
* notify
* echo
The following protection matrix defines which processes (grouped by layer) can use which particular IPC primitives.

[[Image:Protection matrix concerned with Minix IPC primitives.png]]

The table is defined by [http://www.minix3.org/doc/AppendixB.html#TSK_T-06056 lines 06053--06058 in the Minix source code].

== Protection matrix that defines which processes can talk to which other processes ==

The operating system is composed from multiple processes:
* '''SYSTEM''' (the system task)
* '''PM''' (the process manager)
* '''FS''' (the file system)
* '''RS''' (the reincarnation server)
* '''MEM''' (the memory driver)
* '''LOG''' (the logging driver)
* '''TTY''' (the terminal driver)
* '''DS''' (the data server)
* '''INIT''' (the init process)
* '''CLOCK''' (the clock driver)
The following matrix defines allwed interaction (via IPC primitives) among them.

[[Image:Protection matrix concerned with communication between Minix layers.png]]

The table is defined by [http://www.minix3.org/doc/AppendixB.html#s(n)-06067 06060--06071 in the Minix source code].

== Protection matrix that defines which processes can use which "kernel calls" ==

Even though most of the Minix operating system is implemented by a set of user-space processes, there are actions that cannot be done by user space processes. They were refactored to '''SYSTEM''' task which runs in the kernel space and, when these services are invoked, it performs them on behalf of the invoker. The '''SYSTEM''' task supports the following services:
* <tt>sys_fork</tt>
* <tt>sys_exec</tt>
* <tt>sys_exit</tt>
* <tt>sys_nice</tt>
* ...

The protection matrix defines which services of the '''SYSTEM''' task can be invoked by which processes.

[[Image:Protection matrix concerned with kernel calls.png]]

The table is defined by [http://www.minix3.org/doc/AppendixB.html#c(n)-06078 06073--06086 in the Minix source code].

== Known problems ==

The Minix version 3.1.1 distributed with [http://www.amazon.com/Operating-Systems-Implementation-Prentice-Software/dp/0131429388/ref=sr_1_14?ie=UTF8&s=books&qid=1245137182&sr=8-14 the book] has some known problems. They were [http://fixunix.com/minix/28700-how-completely-crash-minix.html reported] and addressed in the subsequent Minix version.

=== A trivial denial of service (DoS) attack ===

Any device driver can cause deadlock (denial of service) of the whole operating system. Let us consider the following trivial device driver code:

#include "../drivers.h"
void main(void)
{
message mess;
while (TRUE)
receive(ANY, &mess);
}

If we compile it and register it as a new device driver then the system will work until someone tries to invoke services of that device driver---e.g. by opening appropriate special file. If we try to do that, the file system server ('''FS''') will remain in a deadlock forever and subsequently all user space processes that will request some operation from the file system server will block forever too.

Newer version of Minix will have to offer slightly different IPC primitives that enable file system server ('''FS''') to guard itself from such malbehaving device drivers and continue providing expected services.

=== Device drivers in Minix have the authority to overwrite any part of the memory ===

Moving as much services of the operating system to a user space is a step forward. However, what we should ultimately seek is the ability to follow the [[POLA|principle of least authority]]. We should try to infer [[authority]] from [[Subject, object, operation and permission|permissions]] of particular [[Subject, object, operation and permission|subjects]]. This should be done at design time as well as during security audit.

If we inspect protection matrixes we reveal that:
* all device drivers are allowed to use the <tt>sendrec</tt> IPC primitive
* all device drivers are allowed to talk to the '''SYSTEM''' task
* all device drivers are allowed to invoke the <tt>sys_physcopy</tt> service of the '''SYSTEM''' task
These are permissions. Translated to human speach---all device drivers have the [[authority]] to overwrite any byte in the physical memory.

This is one of many instances of the [[confused deputy]] probem. It is impossible to solve the problem by some trivial extension of the protection matrices described above. The problem will be elegantly solved by memory-capabilities ("memory grants" in Minix terminology). Processes can create capabilities to regions of their own address space and pass these capabilities to other processes which will be able to read or write to given memory region.

Kosik at 17:48, 20 June 2009

Kosik — Sat, 20 Jun 2009 17:48:06 GMT

←Older revision		Revision as of 17:48, 20 June 2009
Line 112:		Line 112:
	These are permissions. Translated to human speach---all device drivers have the [[authority]] to overwrite any byte in the physical memory.		These are permissions. Translated to human speach---all device drivers have the [[authority]] to overwrite any byte in the physical memory.

-	This is one of many instances of the [[confused deputy ~~problem~~]]. It is impossible to solve the problem by some trivial extension of the protection matrices described above. The problem will be elegantly solved by memory-capabilities ("memory grants" in Minix terminology). Processes can create capabilities to regions of their own address space and pass these capabilities to other processes which will be able to read or write to given memory region.	+	This is one of many instances of the [[confused deputy]] probem. It is impossible to solve the problem by some trivial extension of the protection matrices described above. The problem will be elegantly solved by memory-capabilities ("memory grants" in Minix terminology). Processes can create capabilities to regions of their own address space and pass these capabilities to other processes which will be able to read or write to given memory region.

Kosik: Description of some of the existing problems with the described protection scheme.

Kosik — Sat, 20 Jun 2009 17:44:31 GMT

Description of some of the existing problems with the described protection scheme.

←Older revision		Revision as of 17:44, 20 June 2009
Line 30:		Line 30:
	Ordinary processes run in '''Layer 4'''.		Ordinary processes run in '''Layer 4'''.

-	The following section describe various examples of protection matrixes present internally within Minix. Each of them is enforced by the '''KERNEL''' task.	+	The following section describe various examples of protection matrixes present internally within Minix. Each of them is enforced by the '''KERNEL''' task. Subjects can try to perform any operation on any objects, but the '''KERNEL''' task subsequently checks whether a given subject has permission to perform a chosen operation. Minix is thus an [[ambient authority system]].

	== Protection matrix that defines which processes can use which IPC mechanisms ==		== Protection matrix that defines which processes can use which IPC mechanisms ==
Line 80:		Line 80:
	The table is defined by [http://www.minix3.org/doc/AppendixB.html#c(n)-06078 06073--06086 in the Minix source code].		The table is defined by [http://www.minix3.org/doc/AppendixB.html#c(n)-06078 06073--06086 in the Minix source code].

-	==	+	== Known problems ==
		+
		+	The Minix version 3.1.1 distributed with [http://www.amazon.com/Operating-Systems-Implementation-Prentice-Software/dp/0131429388/ref=sr_1_14?ie=UTF8&s=books&qid=1245137182&sr=8-14 the book] has some known problems. They were [http://fixunix.com/minix/28700-how-completely-crash-minix.html reported] and addressed in the subsequent Minix version.
		+
		+	=== A trivial denial of service (DoS) attack ===
		+
		+	Any device driver can cause deadlock (denial of service) of the whole operating system. Let us consider the following trivial device driver code:
		+
		+	#include "../drivers.h"
		+
		+	void main(void)
		+	{
		+	message mess;
		+
		+	while (TRUE)
		+	receive(ANY, &mess);
		+	}
		+
		+	If we compile it and register it as a new device driver then the system will work until someone tries to invoke services of that device driver---e.g. by opening appropriate special file. If we try to do that, the file system server ('''FS''') will remain in a deadlock forever and subsequently all user space processes that will request some operation from the file system server will block forever too.
		+
		+	Newer version of Minix will have to offer slightly different IPC primitives that enable file system server ('''FS''') to guard itself from such malbehaving device drivers and continue providing expected services.
		+
		+	=== Device drivers in Minix have the authority to overwrite any part of the memory ===
		+
		+	Moving as much services of the operating system to a user space is a step forward. However, what we should ultimately seek is the ability to follow the [[POLA\|principle of least authority]]. We should try to infer [[authority]] from [[Subject, object, operation and permission\|permissions]] of particular [[Subject, object, operation and permission\|subjects]]. This should be done at design time as well as during security audit.
		+
		+	If we inspect protection matrixes we reveal that:
		+	* all device drivers are allowed to use the <tt>sendrec</tt> IPC primitive
		+	* all device drivers are allowed to talk to the '''SYSTEM''' task
		+	* all device drivers are allowed to invoke the <tt>sys_physcopy</tt> service of the '''SYSTEM''' task
		+	These are permissions. Translated to human speach---all device drivers have the [[authority]] to overwrite any byte in the physical memory.
		+
		+	This is one of many instances of the [[confused deputy problem]]. It is impossible to solve the problem by some trivial extension of the protection matrices described above. The problem will be elegantly solved by memory-capabilities ("memory grants" in Minix terminology). Processes can create capabilities to regions of their own address space and pass these capabilities to other processes which will be able to read or write to given memory region.

Kosik at 16:53, 20 June 2009

Kosik — Sat, 20 Jun 2009 16:53:07 GMT

←Older revision		Revision as of 16:53, 20 June 2009
Line 1:		Line 1:
		+	This page documents some of the concrete examples of the [[protection matrix]] concept. In this case, from the Minix world. We first describe lightly describe the structure of the Minix operating system and then we list various different protection matrixes that define certain security policies.
		+
	== Minix structure ==		== Minix structure ==

Line 77:		Line 79:

	The table is defined by [http://www.minix3.org/doc/AppendixB.html#c(n)-06078 06073--06086 in the Minix source code].		The table is defined by [http://www.minix3.org/doc/AppendixB.html#c(n)-06078 06073--06086 in the Minix source code].
		+
		+	==

Kosik: Added references to the Minix source code to spots that defines particular protection matrixes.

Kosik — Sat, 20 Jun 2009 16:39:24 GMT

Added references to the Minix source code to spots that defines particular protection matrixes.

←Older revision		Revision as of 16:39, 20 June 2009
Line 41:		Line 41:

	[[Image:Protection matrix concerned with Minix IPC primitives.png]]		[[Image:Protection matrix concerned with Minix IPC primitives.png]]
		+
		+	The table is defined by [http://www.minix3.org/doc/AppendixB.html#TSK_T-06056 lines 06053--06058 in the Minix source code].

	== Protection matrix that defines which processes can talk to which other processes ==		== Protection matrix that defines which processes can talk to which other processes ==
Line 58:		Line 60:

	[[Image:Protection matrix concerned with communication between Minix layers.png]]		[[Image:Protection matrix concerned with communication between Minix layers.png]]
		+
		+	The table is defined by [http://www.minix3.org/doc/AppendixB.html#s(n)-06067 06060--06071 in the Minix source code].

	== Protection matrix that defines which processes can use which "kernel calls" ==		== Protection matrix that defines which processes can use which "kernel calls" ==
Line 71:		Line 75:

	[[Image:Protection matrix concerned with kernel calls.png]]		[[Image:Protection matrix concerned with kernel calls.png]]
		+
		+	The table is defined by [http://www.minix3.org/doc/AppendixB.html#c(n)-06078 06073--06086 in the Minix source code].

Kosik: minor cleanup

Kosik — Sat, 20 Jun 2009 16:12:51 GMT

minor cleanup

←Older revision		Revision as of 16:12, 20 June 2009
Line 1:		Line 1:
	== Minix structure ==		== Minix structure ==

-	[http://www.minix3.org Minix3] operating system provides classical UNIX-like environment. It provides usual UNIX system calls (fork, exec, exit, kill, open, read, write, etc.) From this point of view, we would have no reason it to prefer it over, say Linux or FreeBSD.	+	[http://www.minix3.org Minix3] operating system provides classical UNIX-like environment. It provides usual UNIX system calls (fork, exec, exit, kill, open, read, write, etc.) From this point of view, we would have no reason it to prefer it over, say, Linux or FreeBSD.

-	The goal of the Minix project is to improve the internal quality of the operating system implementation. Why and how it is done is described in the [http://www.amazon.com/Operating-Systems-Implementation-Prentice-Software/dp/0131429388/ref=sr_1_14?ie=UTF8&s=books&qid=1245137182&sr=8-14 Minix book].	+	The goal of the Minix project is to improve the internal quality of the operating system implementation. Why and how is it done is described in the [http://www.amazon.com/Operating-Systems-Implementation-Prentice-Software/dp/0131429388/ref=sr_1_14?ie=UTF8&s=books&qid=1245137182&sr=8-14 Minix book].

	The following figure captures the structure of the Minix operating system:		The following figure captures the structure of the Minix operating system:
Line 9:		Line 9:
	[[Image:Minix-structure.png]]		[[Image:Minix-structure.png]]

-	Processes in Layer 1 run in the ''kernel space''. Processes in Layers 2, 3 and 4 run in the ''user space''. ~~All ordinary~~ user space ~~programs that Minix user runs explicitely~~ run in Layer 4. Processes that together actually ~~implements~~ the UNIX-like services run in Layers 1, 2 and 3.	+	Processes in Layer 1 run in the kernel space. Processes in Layers 2, 3 and 4 run in the ''user space''. Ordinary user space processes run in Layer 4. Processes that together actually implement the UNIX-like services run in Layers 1, 2 and 3.

	'''Layer 1''' contains:		'''Layer 1''' contains:
-	* the '''KERNEL''' task (it implements the scheduler, it provides the inter-process communications ~~mechanisms~~ used by other processes, it is hooked to IRQs, it enforces security policies defined by protection matrices described below, etc)	+	* the '''KERNEL''' task (it implements the scheduler, it provides the inter-process communications primitives used by other processes, it is hooked to IRQs, it enforces security policies defined by protection matrices described below, etc)
-	* the '''SYSTEM''' task provides various services to user space processes from layers 2 and 3 that must be performed in the kernel space (I/O operations and such). Minix ~~designers call these services as~~ "kernel calls".	+	* the '''SYSTEM''' task provides various services to user space processes from layers 2 and 3 that must be performed in the kernel space (I/O operations and such). In Minix terminology, they are called "kernel calls".
-	* the '''~~clock~~''' task is actually a device driver of the PIT (Programmable Interface Timer chip) that would be hard to move to user space so it runs in the kernel space.	+	* the '''CLOCK''' task is actually a device driver of the PIT (Programmable Interface Timer chip) that would be hard to move to user space so it runs in the kernel space.
-	Minix ~~designers use the term "task" to refer to~~ processes running in '''Layer 1'''.	+	In Minix terminology, processes running in '''Layer 1''' are called '''tasks'''.

-	'''Layer 2''' contains various processes that ~~act~~ as ~~user-space~~ device drivers ('''DRV''').	+	'''Layer 2''' contains various processes that behave as device drivers ('''DRV''').

	'''Layer 3''' contains various higher level subsystems:		'''Layer 3''' contains various higher level subsystems:
-	* "process manager" ('''PM''') implements most of the UNIX services that are related to processes	+	* The process manager ('''PM''') implements most of the UNIX services that are related to processes.
-	* "file system" ('''FS''') implements most of the UNIX services that are related to files	+	* The file system ('''FS''') implements most of the UNIX services that are related to files.
-	* "reincarnation server" ('''RS''') ~~which~~ periodically ~~check (as a heart-beat)~~ whether particular device ~~driver~~ run. It restarts those that crashed (due to segmentation fault~~, for example~~).	+	* The reincarnation server ('''RS''') periodically checks whether particular device drivers run. It restarts those that crashed (e.g. due to a segmentation fault).
-	* "data server" ('''DS''') can be used by device drivers to store their internal state so that restart of the device driver is not ~~visible to observers~~.	+	* The data server ('''DS''') can be used by device drivers to store their internal state so that restart of the device driver does not disrupt the on-going services provided by this driver.
	* etc.		* etc.

-	~~Programs explicitely~~ run ~~by Minix user appear~~ in '''Layer 4'''.	+	Ordinary processes run in '''Layer 4'''.

	The following section describe various examples of protection matrixes present internally within Minix. Each of them is enforced by the '''KERNEL''' task.		The following section describe various examples of protection matrixes present internally within Minix. Each of them is enforced by the '''KERNEL''' task.
Line 38:		Line 38:
	* notify		* notify
	* echo		* echo
-	The following protection matrix defines which (~~group of~~) ~~processes~~ can use which particular IPC primitives.	+	The following protection matrix defines which processes (grouped by layer) can use which particular IPC primitives.

	[[Image:Protection matrix concerned with Minix IPC primitives.png]]		[[Image:Protection matrix concerned with Minix IPC primitives.png]]
-
-	~~(Group of) processes are '''subjects'''. Particular IPC primitives are '''objects'''. Operation is invocation of a given IPC primitive.~~

	== Protection matrix that defines which processes can talk to which other processes ==		== Protection matrix that defines which processes can talk to which other processes ==
Line 57:		Line 55:
	* '''INIT''' (the init process)		* '''INIT''' (the init process)
	* '''CLOCK''' (the clock driver)		* '''CLOCK''' (the clock driver)
-	The following matrix defines allwed interaction (via IPC primitives) among ~~processes~~.	+	The following matrix defines allwed interaction (via IPC primitives) among them.

	[[Image:Protection matrix concerned with communication between Minix layers.png]]		[[Image:Protection matrix concerned with communication between Minix layers.png]]
-
-	~~In this case, rows are (groups of) '''subjects''' and columns are '''objects'''. '''Operation''' in this case is any IPC primitive.~~

	== Protection matrix that defines which processes can use which "kernel calls" ==		== Protection matrix that defines which processes can use which "kernel calls" ==

-	Even though most of the Minix operating system is implemented as a set of user-space processes, there are actions that cannot be done by user space processes. They were refactored to '''SYSTEM''' task which runs in the kernel space and, when these services are invoked, it performs them on behalf of the invoker. The '''SYSTEM''' task supports the following services:	+	Even though most of the Minix operating system is implemented by a set of user-space processes, there are actions that cannot be done by user space processes. They were refactored to '''SYSTEM''' task which runs in the kernel space and, when these services are invoked, it performs them on behalf of the invoker. The '''SYSTEM''' task supports the following services:
	* <tt>sys_fork</tt>		* <tt>sys_fork</tt>
	* <tt>sys_exec</tt>		* <tt>sys_exec</tt>
Line 75:		Line 71:

	[[Image:Protection matrix concerned with kernel calls.png]]		[[Image:Protection matrix concerned with kernel calls.png]]
-
-	~~In this case, rows are (groups of) '''subjects''' and columns are are '''objects'''. '''Operation''' in this case is invocation of a particular service of the '''SYSTEM''' task.~~

Kosik: initial version

Kosik — Sat, 20 Jun 2009 15:38:39 GMT

initial version

←Older revision		Revision as of 15:38, 20 June 2009
Line 1:		Line 1:
-	This page documents some of the concrete examples of the [[protection matrix]] concept. In this case, from the Minix world. We first describe lightly describe the structure of the Minix operating system and then we list various different protection matrixes that define certain security policies.
-
	== Minix structure ==		== Minix structure ==

-	[http://www.minix3.org Minix3] operating system provides classical UNIX-like environment. It provides usual UNIX system calls (fork, exec, exit, kill, open, read, write, etc.) From this point of view, we would have no reason it to prefer it over, say, Linux or FreeBSD.	+	[http://www.minix3.org Minix3] operating system provides classical UNIX-like environment. It provides usual UNIX system calls (fork, exec, exit, kill, open, read, write, etc.) From this point of view, we would have no reason it to prefer it over, say Linux or FreeBSD.

-	The goal of the Minix project is to improve the internal quality of the operating system implementation. Why and how is it done is described in the [http://www.amazon.com/Operating-Systems-Implementation-Prentice-Software/dp/0131429388/ref=sr_1_14?ie=UTF8&s=books&qid=1245137182&sr=8-14 Minix book].	+	The goal of the Minix project is to improve the internal quality of the operating system implementation. Why and how it is done is described in the [http://www.amazon.com/Operating-Systems-Implementation-Prentice-Software/dp/0131429388/ref=sr_1_14?ie=UTF8&s=books&qid=1245137182&sr=8-14 Minix book].

	The following figure captures the structure of the Minix operating system:		The following figure captures the structure of the Minix operating system:
Line 11:		Line 9:
	[[Image:Minix-structure.png]]		[[Image:Minix-structure.png]]

-	Processes in Layer 1 run in the kernel space. Processes in Layers 2, 3 and 4 run in the ''user space''. ~~Ordinary~~ user space ~~processes~~ run in Layer 4. Processes that together actually ~~implement~~ the UNIX-like services run in Layers 1, 2 and 3.	+	Processes in Layer 1 run in the ''kernel space''. Processes in Layers 2, 3 and 4 run in the ''user space''. All ordinary user space programs that Minix user runs explicitely run in Layer 4. Processes that together actually implements the UNIX-like services run in Layers 1, 2 and 3.

	'''Layer 1''' contains:		'''Layer 1''' contains:
-	* the '''KERNEL''' task (it implements the scheduler, it provides the inter-process communications ~~primitives~~ used by other processes, it is hooked to IRQs, it enforces security policies defined by protection matrices described below, etc)	+	* the '''KERNEL''' task (it implements the scheduler, it provides the inter-process communications mechanisms used by other processes, it is hooked to IRQs, it enforces security policies defined by protection matrices described below, etc)
-	* the '''SYSTEM''' task provides various services to user space processes from layers 2 and 3 that must be performed in the kernel space (I/O operations and such). In Minix ~~terminology, they are called~~ "kernel calls".	+	* the '''SYSTEM''' task provides various services to user space processes from layers 2 and 3 that must be performed in the kernel space (I/O operations and such). Minix designers call these services as "kernel calls".
-	* the '''~~CLOCK~~''' task is actually a device driver of the PIT (Programmable Interface Timer chip) that would be hard to move to user space so it runs in the kernel space.	+	* the '''clock''' task is actually a device driver of the PIT (Programmable Interface Timer chip) that would be hard to move to user space so it runs in the kernel space.
-	In Minix ~~terminology,~~ processes running in '''Layer 1~~''' are called '''tasks~~'''.	+	Minix designers use the term "task" to refer to processes running in '''Layer 1'''.

-	'''Layer 2''' contains various processes that ~~behave~~ as device drivers ('''DRV''').	+	'''Layer 2''' contains various processes that act as user-space device drivers ('''DRV''').

	'''Layer 3''' contains various higher level subsystems:		'''Layer 3''' contains various higher level subsystems:
-	* ~~The~~ process manager ('''PM''') implements most of the UNIX services that are related to processes.	+	* "process manager" ('''PM''') implements most of the UNIX services that are related to processes
-	* ~~The~~ file system ('''FS''') implements most of the UNIX services that are related to files.	+	* "file system" ('''FS''') implements most of the UNIX services that are related to files
-	* ~~The~~ reincarnation server ('''RS''') periodically ~~checks~~ whether particular device ~~drivers~~ run. It restarts those that crashed (~~e.g.~~ due to a segmentation fault).	+	* "reincarnation server" ('''RS''') which periodically check (as a heart-beat) whether particular device driver run. It restarts those that crashed (due to segmentation fault, for example).
-	* ~~The~~ data server ('''DS''') can be used by device drivers to store their internal state so that restart of the device driver ~~does~~ not ~~disrupt the on-going services provided by this driver~~.	+	* "data server" ('''DS''') can be used by device drivers to store their internal state so that restart of the device driver is not visible to observers.
	* etc.		* etc.

-	~~Ordinary processes~~ run in '''Layer 4'''.	+	Programs explicitely run by Minix user appear in '''Layer 4'''.

-	The following section describe various examples of protection matrixes present internally within Minix. Each of them is enforced by the '''KERNEL''' task. Subjects can try to perform any operation on any objects, but the '''KERNEL''' task subsequently checks whether a given subject has permission to perform a chosen operation. Minix is thus an [[ambient authority system]].	+	The following section describe various examples of protection matrixes present internally within Minix. Each of them is enforced by the '''KERNEL''' task.

	== Protection matrix that defines which processes can use which IPC mechanisms ==		== Protection matrix that defines which processes can use which IPC mechanisms ==
Line 40:		Line 38:
	* notify		* notify
	* echo		* echo
-	The following protection matrix defines which ~~processes~~ (~~grouped by layer~~) can use which particular IPC primitives.	+	The following protection matrix defines which (group of) processes can use which particular IPC primitives.

	[[Image:Protection matrix concerned with Minix IPC primitives.png]]		[[Image:Protection matrix concerned with Minix IPC primitives.png]]

-	~~The table is defined by [http://www~~.~~minix3~~.~~org/doc/AppendixB.html#TSK_T-06056 lines 06053--06058 in the Minix source code]~~.	+	(Group of) processes are '''subjects'''. Particular IPC primitives are '''objects'''. Operation is invocation of a given IPC primitive.

	== Protection matrix that defines which processes can talk to which other processes ==		== Protection matrix that defines which processes can talk to which other processes ==
Line 59:		Line 57:
	* '''INIT''' (the init process)		* '''INIT''' (the init process)
	* '''CLOCK''' (the clock driver)		* '''CLOCK''' (the clock driver)
-	The following matrix defines allwed interaction (via IPC primitives) among ~~them~~.	+	The following matrix defines allwed interaction (via IPC primitives) among processes.

	[[Image:Protection matrix concerned with communication between Minix layers.png]]		[[Image:Protection matrix concerned with communication between Minix layers.png]]

-	~~The table is defined by [http://www.minix3.org/doc/AppendixB.html#s~~(n)~~-06067 06060--06071~~ in ~~the Minix source code]~~.	+	In this case, rows are (groups of) '''subjects''' and columns are '''objects'''. '''Operation''' in this case is any IPC primitive.

	== Protection matrix that defines which processes can use which "kernel calls" ==		== Protection matrix that defines which processes can use which "kernel calls" ==

-	Even though most of the Minix operating system is implemented by a set of user-space processes, there are actions that cannot be done by user space processes. They were refactored to '''SYSTEM''' task which runs in the kernel space and, when these services are invoked, it performs them on behalf of the invoker. The '''SYSTEM''' task supports the following services:	+	Even though most of the Minix operating system is implemented as a set of user-space processes, there are actions that cannot be done by user space processes. They were refactored to '''SYSTEM''' task which runs in the kernel space and, when these services are invoked, it performs them on behalf of the invoker. The '''SYSTEM''' task supports the following services:
	* <tt>sys_fork</tt>		* <tt>sys_fork</tt>
	* <tt>sys_exec</tt>		* <tt>sys_exec</tt>
Line 78:		Line 76:
	[[Image:Protection matrix concerned with kernel calls.png]]		[[Image:Protection matrix concerned with kernel calls.png]]

-	~~The table is defined by [http://www.minix3.org/doc/AppendixB.html#c~~(~~n)-06078 06073--06086 in the Minix source code].~~	+	In this case, rows are (groups of) '''subjects''' and columns are are '''objects'''. '''Operation''' in this case is invocation of a particular service of the '''SYSTEM''' task.
-		+
-	~~== Known problems ==~~	+
-		+
-	The Minix version 3.1.1 distributed with [http://www.amazon.com/Operating-Systems-Implementation-Prentice-Software/dp/0131429388/ref=sr_1_14?ie=UTF8&s=books&qid=1245137182&sr=8-14 the book] has some known problems. They were [http://fixunix.com/minix/28700-how-completely-crash-minix.html reported] and addressed in the subsequent Minix version.	+
-		+
-	~~=== A trivial denial~~ of ~~service (DoS~~) ~~attack ===~~	+
-		+
-	~~Any device driver can cause deadlock (denial of service) of the whole operating system. Let us consider the following trivial device driver code:~~	+
-		+
-	~~#include "../drivers.h"~~	+
-	~~void main(void)~~	+
-	{	+
-	~~message mess;~~	+
-	~~while (TRUE)~~	+
-	~~receive(ANY, &mess);~~	+
-	}	+
-		+
-	If we compile it and register it as a new device driver then the system will work until someone tries to invoke services of that device driver---e.g. by opening appropriate special file. If we try to do that, the file system server ('''FS'''~~) will remain in a deadlock forever~~ and ~~subsequently all user space processes that will request some operation from the file system server will block forever too.~~	+
-		+
-	~~Newer version of Minix will have to offer slightly different IPC primitives that enable file system server (~~'''FS'''~~) to guard itself from such malbehaving device drivers and continue providing expected services~~.	+
-		+
-	~~=== Device drivers in Minix have the authority to overwrite any part of the memory ===~~	+
-		+
-	Moving as much services of the operating system to a user space is a step forward. However, what we should ultimately seek is the ability to follow the [[POLA\|principle of least authority]]. We should try to infer [[authority]] from [[Subject, object, operation and permission\|permissions]] of particular [[Subject, object, operation and permission\|subjects]]. This should be done at design time as well as during security audit.	+
-		+
-	~~If we inspect protection matrixes we reveal that:~~	+
-	* all device drivers are allowed to use the <tt>sendrec</tt> IPC primitive	+
-	* all device drivers are allowed to talk to the '''~~SYSTEM~~''' ~~task~~	+
-	* all device drivers are allowed to invoke the <tt>sys_physcopy</tt> service of the '''SYSTEM''' task	+
-	~~These are permissions. Translated to human speach---all device drivers have the [[authority]] to overwrite any byte in the physical memory.~~	+
-		+
-	This is one of many instances of the [[confused deputy]] probem. It is impossible to solve the problem by some trivial extension of the protection matrices described above. The problem will be elegantly solved by memory-capabilities ("memory grants" in Minix terminology). Processes can create capabilities to regions of their own address space and pass these capabilities to other processes which will be able to read or write to given memory region.	+