Attached is the second release of FPP. Support has been added for the
new policy language constructs merge_type, clone_type, and add and
remove blocks.
1. merge_type
merge_type type type;
The purpose of merge_type statement is to make it easier to merge types
together. When processed, the type declaration of the first type listed
is removed and the first type is made to be a typealias of the second
type listed. Merging to a type that is also being merged is allowed and
correctly handled.
2. clone_type
clone_type type type;
clone_type type type {
TE_rules_to_be_removed
}
The purpose of this statement is to make it easier to split types and to
create new types derived from old types. It is similar to what type
inheritance would be, except the rules are copied and no kernel support
is needed. A cloned type can optionally remove access vector rules by
specifying those rules in an optional remove block. Currently, the rules
to be removed are not required to have anything to do with either the
old or new type--this might prove to be bad.
Dependencies are handled as follows. If c1 is cloning c2, then c1 will
not be processed until c2 has been cloned. If c1 is cloning a type that
is modified in c2's remove block, then c1 will not be processed until
after c2's remove block has been processed. But in the case where c1 is
cloning a type that is modified in the remove block of c2 which is
cloning c1, the dependency based on the type modification will be
ignored. The cloning dependency is stronger than the type modification
dependency.
When the rules are removed, attributes will be expanded as required so
that the permission can be removed.
3. add and remove blocks
add|remove {
policy_statements
}
The purpose of the add and remove statements is to make local
customization of policy easier and to allow the local customizations to
be kept separate from the distributed policy (even when removing
permissions).
The goal is to be able to have something like a policy patch, but there
is an important difference. When an access vector rule is removed, the
actual permission is removed, so even though multiple policy statements
may have allowed that permission, only one statement in a remove block
is required to remove the permission. This means that if an interface
call is in a remove block, all of the permissions that it grants will be
removed, even the permissions that are granted by other interfaces.
When removing access vector rules, attributes will be expanded as
necessary so that the permission can be removed.
It is not entirely clear what the best way to determine what statements
other than access vector rules should be removed. Should the match be
made on the smallest amount of information needed to uniquely match, or
should there be a requirement to exactly match the whole statement? I am
currently using the smallest amount of information needed to uniquely
match in most cases. For dominance, role, typealias, and typeattribute
statements, depending on what is in the remove block, only part of the
statement may be removed. On the other hand, constraint statements must
match exactly.
Declarations in add or remove blocks are processed after declarations
are processed, the rest of the statements after statements are
processed.
Examples:
Ex1:
merge_type t1 t2;
merge_type t2 t3;
In example Ex1, t3 will end up with t1 and t2 as typealiases.
Ex2:
clone_type d4 d3 {
allow d4 f3 : C1 P1;
}
clone_type d5 d4 {
allow d4 f3 : C2 P2;
}
clone_type d6 d1 {
allow f3 d3 : C3 P3;
}
clone_type d7 d1;
clone_type d7 d2;
In example Ex2, four types are being created d4, d5, d6,and d7. d4 is
cloned from d3, but since d6 is modifying a rule involving d3, d4 will
not be cloned until after d6 is. d5 is also modifying d3, but since d5
is being cloned from d4, d4 will still be processed first. d7 is created
by cloning two types. Since d4 will be a member of A, the rule "allow A
f3 : C1 P1;" needs to be expanded so that the rule "allow d4 f3 : C1
P1;" can be removed.
Ex3:
remove {
allow t1 t2 : C1 P1;
typeattribute t1 a2;
if (B){
allow t1 t2 : C1 P3;
}
fs_use_xattr FS1 u:r:t1:s;
mlsvalidatetrans { C1 } ( t3 == A );
constrain C1 P1 ( t1 != A );
genfscon FS2 / u:r:t1:s
portcon P 1 u:r:t1:s
}
In example Ex3, if t1 has attribute a1, a2, and a3, only a2 will be
removed. The context does not need to match for the fs_use_xattr,
genfscon, or portcon statements to be removed. The constraint
expressions for the constrain and mlsvalidatetrans statements must match
exactly.
--
James Carter <jwcart2@xxxxxxxxxxxxx>
National Security Agency
Attachment:
fpp_20090413.tar.bz2
Description: application/bzip-compressed-tar
