RFC: Requirements for MAC policies and implementation

[Magosányi Árpád]

A levelezőm azt hiszi, hogy Robert Watson a következőeket írta:
[]
> - Multi-Level Security Model (MLS)
> - Biba Integrity Model
> - Strong Non-Intersecting Partition Model
-Low water mark model
-Fisher-Hübner privacy model
-Role-based access control

I am increasingly on the opinion that if you want to implement some
sensitivity oriented MAC, like Bell-LaPadula, there are also some
features that should be there to make a system work with only
light modifications. One such issue is the virtualisation of namespaces.
If you use sensitivity oriented MAC combined with non-intersecting partitions,
it is all okay. But if you use it in one namespace, there are problems
like 'what is the label of /tmp?'. The file redirection feature of Medusa
(if it would work) is an elegant way to resolve these issues. (another way
is to make all programs aware of the situation, but I think it isn't
feasible even with the closed development model of BSD.)

> - Labeling Issues

	I think the network related things could be adressed elegantly
	from the packet filter side. I am thinking of something like
	the "fwmark" feature, where the packet filter rules can mark
	incoming packets. The network sockets could be labeled by
	the creating process (either implicitly or explicitly),
	and the implicit narrowing and the access control could be
	done using the packets' label. The labels of an interface
	could also be a factor in the computing the label of a packet
	or a socket, but I feel it is unnecessary if we base the marking
	on the packet filter rules (you can be selective based on 
	interface there).
	From the flow control point of view an interface or a network 
	socket is a communication channel, and not a system object.
	And as such, they labels should be designated (either implicitly
	or explicitly) by the authorized administrator, and the access
	to them should be governed by the importation and exportation 
	rules.
	This means that the labels associated by the packet filters should
	be labelsets instead, which can describe the minimal and maximal
	label of an interface, and there are rules which can narrow
	a labelset of an object/channel.
	[Add a distinction between data and control, define sensitivity
	and integrity rules for both, and you will get Zorp's access
	control model:]
	

> - Access Control Points
> 	- Access control points for mandatory policies would certainly
> 	  include all existing discretionary access control points (file
> 	  name lookup and open operations, socket creation, inter-process
> 	  control such as signaling and debugging), but what other
> 	  points may now require access control or revocation?
> 
> 	- Floating label schemes would require access control and
> 	  revocation at the granularity of individual reads/writes
> 	  rather than the DAC cached credential model for file and
> 	  socket access.  Revocation even in non-floating schemes might
> 	  demand blocking access to previously accessible services
> 	  such as file descriptors and sockets, based on the requirements
> 	  of the scheme.  Similarly, shared memory resources might
> 	  fall under revocation environments, something that the VM
> 	  system has not been designed for.

The TCSEC interpretation is clear abut revocation:
	You are not required to promptly revoke a resource which is given
	to a user if her rights which made her eligible to get the resource
	has been revoked. So you can wait with freeing memory
	until the process exits, and in a static label scheme you
	are not even required to knock out that label from the proc
	structure when it is changed in "/etc/passwd".


> For reference with regards to long term development plans, this MAC
> implementation would be prior to the implementation of a generalized
> labeling and access control scheme such as Poligraph, but would be a
> useful step towards the implementation of such a system, providing a
> stronger understanding of requirements for the implementation of these
> common MAC schemes. 

I just wanted to suggest some generalized framework approach.
In this case I guess this implementation shall choose one sensitivity
(Bell-LaPadula of course), and one integrity (Biba or low water mark 
comes to mind) model, augmented with capability handling , packet filter
change and file redirection.

-- 
GNU GPL: csak tiszta forrásból
To Unsubscribe: send mail to majordomo at trustedbsd.org
with "unsubscribe trustedbsd-discuss" in the body of the message