From: Mark Lawrence (mark_at_holderbank.com)
Date: Sat 09 Aug 2003 - 12:43:22 BST
On Sat, 9 Aug 2003, Herbert Pötzl wrote:
> Opinion Poll!
You're on!
> 1) if the almighty context zero/one modifies files
> of another context ...
>
> a) the files/dirs to keep their context?
> b) the files/dirs change to context zero?
I think a) is a better option. Consider what currently happens with file
ownership, or file permissions. It would make sense to have the same style
of behaviour. I suggest the use of a 'chctx' command (like chmod, chown
etc) to change the context of a file from the zero/one contexts.
> 2) if a program of context N encounters a file of
> context M, where N != M ...
>
> a) on modify change the file to the new context?
> b) do not allow access to files from other contexts
> except context zero/one?
> c) allow modification while keeping the file
> in its 'original' context?
Is not the whole point of a security context to keep the contexts'
separate? Go for b). Treat N!=M as a read permission attribute.
> 3) consider a program creating a (hard)link to a file
> in another context (including zero/one), should ...
> a) the file change to the 'new' context?
> b) the file keep the old context?
> c) this operation be disallowed?
I would suggest disallow this, with one exception.
My philosophy is that contexts are always separate. As far as I know, the
only reason to have any relationship between contexts is to save memory
and buffers (are there other reasons?)
For this case, it might be useful that linking from any context to a file
in a special context (say context 1) _is_ allowed, but invokes a
copy-on-write function when the context attempts to write to the file.
Regards, Mark.
-- Mark Lawrence mark_at_holderbank.com