MAC implementation with definable policy

[Ilmar S. Habibulin]

On Thu, 30 Sep 1999, James Buster wrote:

> } > } Ok. I'm reading file with labelA, then i'm reading file with labelB, which
> } > } dominates labelA. After reading i'm cleating new file. What label should
> } > } it have?
> } > The same label your process has.
> } Ok, process have labelC, that dominates labelB and labelA. So we create
> } file with labelC - why?
> If a process didn't create files having MAC labels equal to its own,
> how do you ensure that it can read and write files it creates?
My point is that if process have access but don't read
SUPER_VERY_SECRET_FILE with VERY_HIGH_MAC_LABEL, it should not create
SOME_GARBAGE_UNNECESSARY_FILE with VERY_HIGH_MAC_LABEL. Am i wrong?
(i'm standing for floating hierarchycal label(or better levels)).

> } That's why i am confused. Your approach is not MAC, as described by papers
> } i read. All of them pointed to BL model.
> It's not BL MAC, but it is MAC. The term Mandatory Access Control can
> be applied to more security models than those using a partially or
> totally ordered lattice.
Only because of MANDATORY? And what about information flow control?

> } And discretionary mechanism exists in BLM - it's non-hyerarchical
> } categories.
> That is not a discretionary mechanism, since the set of non-hierarchical
> categories in a MAC label is not modifiable.
Where can i read about prohibition of changing non-hierarchical
categories? I doesn't found it in draft, maybe i should keep my eyes more
wide open? ;-)
There is another sort of confution, like with levels. Non-hierarchical
categories can be used to point to the project (for ex.) the file related
to. So if person has access to more than one project, he(she) will create
file accessible to all project he(she) has access. Nonsense i suppose.
(that's food thought for me too).


To Unsubscribe: send mail to majordomo at cyrus.watson.org
with "unsubscribe posix1e" in the body of the message