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>
Filenames can have a +, so we should be able to parse and handle those
files.
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 found that we wanted a filename transition rule for ld.so.cache~
however ~ was not a valid character in a filename.
Fix-from: Miroslav Grepl <mgrepl@redhat.com>
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>
In order to support filenames, which might start with "." or filesystems
that start with a number we need to rework the matching rules a little
bit. Since the new filename rule is so permissive it must be moved to
the bottom of the matching list to not cover other definitions.
Signed-of-by: Eric Paris <eparis@redhat.com>
Acked-by: Dan Walsh <dwalsh@redhat.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>
The patch below allows filesystem names in fs_use_* and genfscon
statements to start with a digit, but still requires at least one
character to be a letter. A new token type for filesystem names is
created since these names having nothing to do with SELinux.
This patch is needed because some filesystem names (such as 9p) start
with a digit.
Signed-off-by: James Carter <jwcart2@tycho.nsa.gov>
Signed-off-by: Steve Lawrence <slawrence@tresys.com>
This wraps the filename token in quotes to make parsing easier and more
clear. The quotes are stripped off before being passed to checkpolicy.
The quote wrapping is only used by filename transitions. This changes
the filename transition syntax to the following:
type_transition source target : object default_type "filename";
Signed-off-by: Steve Lawrence <slawrence@tresys.com>
On Tue, 2008-10-14 at 02:00 +0000, korkishko Tymur wrote:
> I have checked policy_parse.y. It has following rule for genfscon:
>
> genfs_context_def : GENFSCON identifier path '-' identifier security_context_def
> {if (define_genfs_context(1)) return -1;}
> | GENFSCON identifier path '-' '-' {insert_id("-", 0);} security_context_def
> {if (define_genfs_context(1)) return -1;}
> | GENFSCON identifier path security_context_def
> {if (define_genfs_context(0)) return -1;}
>
> The rule for path definition (in policy_scan.l) has already included '-' (dash):
>
> "/"({alnum}|[_.-/])* { return(PATH); }
>
> In my understanding (maybe wrong), path is parsed first (and path might include '-') and only then separate '-' is parsed.
> But it still produces an error if path definition is correct and includes '-'.
>
> Any ideas/patches how to fix grammar rules are welcomed.
This looks like a bug in policy_scan.l - we are not escaping (via
backslash) special characters in the pattern and thus the "-" (dash) is
being interpreted rather than taken literally. The same would seemingly
apply for "." (dot), and would seem relevant not only to PATH but also
for IDENTIFIER. The patch below seems to fix this issue for me:
