SELinux by Example: Using Security Enhanced Linux

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:

  1. user_u:user_r:user_t:s0-s0:c0

  2. user_u:user_r:user_t:s0-s1

  3. user_u:user_r:user_t:s0-s1:c0.c4

  4. user_u:user_r:user_t:s1:c0.c2-s2:c0.c1

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

Related

Категории