MAC implementation with definable policy

[James Buster]

On Oct 1,  9:18am, "Ilmar S. Habibulin" wrote:
} 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)).

It sounds like you want information labels. They're not "wrong",
but having implemented a system with them I can say they are
generally useless and annoying.

} > 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?

Yes. For example, "check in with the guard at the gate" is a MAC policy.

} And what about information flow control?

That's not a property of the Mandatory part of MAC. You *could* have
a DAC policy that places attributes on files which look suspiciously like
MAC labels but permit object owners to change the level and/or categories
of those labels. Flow control would still be enforced, but only at an
object owner's discretion.

} Where can i read about prohibition of changing non-hierarchical
} categories?

This assumption is called, I believe, the tranquility property.

Any MAC policy which permitted unprivileged users to change the categories
of MAC labels wouldn't be Mandatory, would it?

} 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.

Only if the user logs in with a label having all those categories.
Users may have more than one MAC label that they may log in with,
and those MAC labels may have different category sets.

-- 
Planet Bog -- pools of toxic chemicals bubble under a choking
atomsphere of poisonous gases... but aside from that, it's not
much like Earth.
To Unsubscribe: send mail to majordomo at cyrus.watson.org
with "unsubscribe posix1e" in the body of the message