On 2013-12-14 05:40, Craig Ringer wrote:
> I find the heirachical and non-heirachical label security model used in
> Teradata to be extremely interesting and worthy of study.
>
> The concept is that there are heirachical label policies (think
> "classified", "unclassified", etc) or non-heirachical (mutually
> exclusive labels). A user can see a row if they have all the policies
> used in a table, and each of the user's policy values is sufficient to
> see the row. For non-heiracical policies that means the user and row
> must have at least one label in common; for heiracical policies it means
> the user label must be greater than or equal to the row label.
>
> That model lets you quite flexibly and easily build complex security
> models. It'd work well with PostgreSQL, too: We could implement
> something like non-heirachical policies using a system varbit column
> that's added whenever a non-heirachical policy gets added to a table,
> and simply AND it with the varbit on the user's policy to see if they
> can access the row. Or use a compact fixed-width bitfield. Heirachical
> policies would use a 1 or 2 byte int system column to store the label.
Is is necessary to fix the attribute type of the security label? The
label model described above seems to restrictive to support e.g. the
labels described on p18 of the 'healthcare classification system' (HCS)
(http://www.hl7.org/documentcenter/public/wg/secure/3.%20HCS%20Guide%20Final%202013%200322%20JMD.pdf).
The HCS security label is based on the NIST's FIPS188 standard /
http://www.itl.nist.gov/fipspubs/fip188.htm
regards,
Yeb Havinga