We currently have a mechanism in which the default user, role, and range
can be picked up from the source or the target object. This implements
the same thing for types. The kernel will override this with type
transition rules and similar. This is just the default if nothing
specific is given.
Signed-off-by: Eric Paris <eparis@redhat.com>
Acked-by: Dan Walsh <dwalsh@redhat.com>
Android/MacOS X build support for checkpolicy.
Create a Android.mk file for Android build integration.
Introduce DARWIN ifdefs for building on MacOS X.
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Signed-off-by: Eric Paris <eparis@redhat.com>
Acked-by: Dan Walsh <dwalsh@redhat.com>
We would like to be able to say that the user, role, or range of a newly
created object should be based on the user, role, or range of either the
source or the target of the creation operation. aka, for a new file
this could be the user of the creating process or the user or the parent
directory. This patch implements the new language and the policydb
support to give this information to the kernel.
Signed-off-by: Eric Paris <eparis@redhat.com>
Acked-by: Dan Walsh <dwalsh@redhat.com>
We use the exact same logic a bunch of places in policy_define.c to
translate a class set into a bitmap. Make this into a helper function.
Signed-off-by: Eric Paris <eparis@redhat.com>
Acked-by: Dan Walsh <dwalsh@redhat.com>
Both boolean and tunable keywords are processed by define_bool_tunable(),
argument 0 and 1 would be passed for boolean and tunable respectively.
For tunable, a TUNABLE flag would be set in cond_bool_datum_t.flags.
Note, when creating an if-else conditional we can not know if the
tunable identifier is indeed a tunable(for example, a boolean may be
misused in tunable_policy() or vice versa), thus the TUNABLE flag
for cond_node_t would be calculated and used in expansion when all
booleans/tunables copied during link.
Signed-off-by: Harry Ciao <qingtao.cao@windriver.com>
Signed-off-by: Eric Paris <eparis@redhat.com>
Acked-by: Dan Walsh <dwalsh@redhat.com>
When the link process is completed, the types type_set_t and roles
ebitmap in a role attribute are settled, then we could go on to scan
all role attributes in the base->p_roles.table checking if any non-zero
bit in its roles ebitmap is indeed another role attribute.
If this is the case, then we need to escalate the roles ebitmap of
the sub role attribute into that of the parent, and remove the sub role
attribute from parent's roles ebitmap.
Since sub-attribute's roles ebitmap may further contain other role
attributes, we need to re-scan the updated parent's roles ebitmap.
Also if a loop dependency is detected, no escalation of sub-attribute's
roles ebitmap is needed.
Note, although in the link stage all role identifiers defined in any
block/decl of any module would be copied into the base->p_roles.table,
the role-attribute relationships could still be recorded in the decl's
local symtab[SYM_ROLES] table(see get_local_role()), so before all above
escalation of sub role attribute's roles ebitmap into that of parent ever
happens, all decl in the base->global list except the global block would
have to be traversed so as to populate potential role-attribute
relationships from decl up to the base module.
Signed-off-by: Harry Ciao <qingtao.cao@windriver.com>
Signed-off-by: Steve Lawrence <slawrence@tresys.com>
When the rolemap and pointer to the base module are available, if
a non-zero bit in role_set_t.roles is a role attribute, expand it
before remap.
Note, during module compile the rolemap may not be available, the
potential duplicates of a regular role and the role attribute that
the regular role belongs to could be properly handled by
copy_role_allow() and copy_role_trans() during module expansion.
Take advantage of the role_val_to_struct[] of the base module, since
when role_set_expand() is invoked, the role_val_to_struct[] of the
out module may have not been established yet.
Also cleanup the error handling of role_set_expand().
Signed-off-by: Harry Ciao <qingtao.cao@windriver.com>
Signed-off-by: Steve Lawrence <slawrence@tresys.com>
1. Add a uint32_t "flavor" field and an ebitmap "roles" to the
role_datum_t structure;
2. Add a new "attribute_role" statement and its handler to declare
a role attribute;
3. Modify declare_role() to setup role_datum_t.flavor according
to the isattr argument;
4. Add a new "roleattribute" rule and its handler, which will record
the regular role's (policy value - 1) into the role attribute's
role_datum_t.roles ebitmap;
5. Modify the syntax for the role-types rule only to define the
role-type associations;
6. Add a new role-attr rule to support the declaration of a single
role, and optionally the role attribute that the role belongs to;
7. Check if the new_role used in role-transition rule is a regular role;
8. Support to require a role attribute;
9. Modify symtab_insert() to allow multiple declarations only for
the regular role, while a role attribute can't be declared more than once
and can't share a same name with another regular role.
Signed-off-by: Harry Ciao <qingtao.cao@windriver.com>
Signed-off-by: Steve Lawrence <slawrence@tresys.com>
This patch adds support for using the last path component as part of the
information in making labeling decisions for new objects. A example
rule looks like so:
type_transition unconfined_t etc_t:file system_conf_t eric;
This rule says if unconfined_t creates a file in a directory labeled
etc_t and the last path component is "eric" (no globbing, no matching
magic, just exact strcmp) it should be labeled system_conf_t.
The kernel and policy representation does not have support for such
rules in conditionals, and thus policy explicitly notes that fact if
such a rule is added to a conditional.
Signed-off-by: Eric Paris <eparis@redhat.com>
Signed-off-by: Steve Lawrence <slawrence@tresys.com>
Handle the class field in the role_transition rule. If no class is
specified, then it would be set to the "process" class by default.
Signed-off-by: Harry Ciao <qingtao.cao@windriver.com>
Signed-off-by: Steve Lawrence <slawrence@tresys.com>
Email: justinmattock@gmail.com
Subject: checkpolicy Fix error: variable 'newattr' set but not used(and others as well)
Date: Tue, 6 Jul 2010 15:23:28 -0700
The below patch fixes some warning messages Im receiving
with GCC:(in this case some are erros due to -Werror)
policy_define.c: In function 'define_type':
policy_define.c:1216:6: error: variable 'newattr' set but not used
cc1: all warnings being treated as errors
Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
Signed-off-by: Chad Sellers <csellers@tresys.com>
The boundry format mapped the primary field to a boolean in the
properties bitmap. This is appropriate for the kernel policy, but in
modular policy the primary field may be an integer that indicates the
primary type that is being aliased. In this case, the primary value cannot
be assumed to be boolean.
This patch creates a new module format that writes out the primary value
as was done before the boundry format.
Signed-off-by: Caleb Case <ccase@tresys.com>
Signed-off-by: Joshua Brindle <method@manicmethod.com>
