Exercises

1.

Assume the following sensitivity and category definitions: sensitivity s0; sensitivity s1; sensitivity s2; category c0; category c1; category c2; category c3; category c4; level s0; level s1:c0.c2; level s2:c0.c4; Also assume user_u, user_r, and user_t are valid user, role, and type identifiers. Determine which of the following security contexts are valid and explain why or why not: user_u:user_r:user_t:s0-s0:c0 user_u:user_r:user_t:s0-s1 user_u:user_r:user_t:s0-s1:c0.c4 user_u:user_r:user_t:s1:c0.c2-s2:c0.c1 user_u:user_r:user_t:s1-s2:c0,c4

2.

Look again at the following MLS constraint: mlsconstrain file { write create setattr relabelfrom append unlink link rename mounton } ( ( l1 domby l2 ) or ( t1 == mlsfilewritedown ) ); This constraint restricts the ability to "write down," but allows any domain to "write up." Indeed, there is no MLS-related reason to restrict "write up" because it does not constitute a downgrading of information, and there are valid uses of this capability to build MLS-aware security applications. Nonetheless, some MLS system developers like to provide a privilege to control "write up" just like "write down." As an exercise, change the preceding constraint to control writing up and down.