Add checkpolicy support for scanning and parsing ibendportcon labels.
Also create a new ocontext for IB end ports.
Signed-off-by: Daniel Jurgens <danielj@mellanox.com>
Add checkpolicy support for scanning and parsing ibpkeycon labels. Also
create a new ocontext for Infiniband Pkeys and define a new policydb
version for infiniband support.
Signed-off-by: Daniel Jurgens <danielj@mellanox.com>
This commit adds attribute expansion statements to the policy
language allowing compiler defaults to be overridden.
Always expands an attribute example:
expandattribute { foo } true;
CIL example:
(expandtypeattribute (foo) true)
Never expand an attribute example:
expandattribute { bar } false;
CIL example:
(expandtypeattribute (bar) false)
Adding the annotations directly to policy was chosen over other
methods as it is consistent with how targeted runtime optimizations
are specified in other languages. For example, in C the "inline"
command.
Motivation
expandattribute true:
Android has been moving away from a monolithic policy binary to
a two part split policy representing the Android platform and the
underlying vendor-provided hardware interface. The goal is a stable
API allowing these two parts to be updated independently of each
other. Attributes provide an important mechanism for compatibility.
For example, when the vendor provides a HAL for the platform,
permissions needed by clients of the HAL can be granted to an
attribute. Clients need only be assigned the attribute and do not
need to be aware of the underlying types and permissions being
granted.
Inheriting permissions via attribute creates a convenient mechanism
for independence between vendor and platform policy, but results
in the creation of many attributes, and the potential for performance
issues when processes are clients of many HALs. [1] Annotating these
attributes for expansion at compile time allows us to retain the
compatibility benefits of using attributes without the performance
costs. [2]
expandattribute false:
Commit 0be23c3f15 added the capability to aggresively remove unused
attributes. This is generally useful as too many attributes assigned
to a type results in lengthy policy look up times when there is a
cache miss. However, removing attributes can also result in loss of
information used in external tests. On Android, we're considering
stripping neverallow rules from on-device policy. This is consistent
with the kernel policy binary which also did not contain neverallows.
Removing neverallow rules results in a 5-10% decrease in on-device
policy build and load and a policy size decrease of ~250k. Neverallow
rules are still asserted at build time and during device
certification (CTS). If neverallow rules are absent when secilc is
run, some attributes are being stripped from policy and neverallow
tests in CTS may be violated. [3] This change retains the aggressive
attribute stripping behavior but adds an override mechanism to
preserve attributes marked as necessary.
[1] https://github.com/SELinuxProject/cil/issues/9
[2] Annotating all HAL client attributes for expansion resulted in
system_server's dropping from 19 attributes to 8. Because these
attributes were not widely applied to other types, the final
policy size change was negligible.
[3] data_file_type and service_manager_type are stripped from AOSP
policy when using secilc's -G option. This impacts 11 neverallow
tests in CTS.
Test: Build and boot Marlin with all hal_*_client attributes marked
for expansion. Verify (using seinfo and sesearch) that permissions
are correctly expanded from attributes to types.
Test: Mark types being stripped by secilc with "preserve" and verify
that they are retained in policy and applied to the same types.
Signed-off-by: Jeff Vander Stoep <jeffv@google.com>
checkpolicy currently imposes arbitrary limits on pathnames used
in genfscon and other statements. This prevents specifying certain
paths in /proc such as those containing comma (,) characters.
Generalize the PATH, QPATH, and FILENAME patterns to support most
legal pathnames.
For simplicity, we do not support pathnames containing newlines or
quotes.
Reported-by: Inamdar Sharif <isharif@nvidia.com>
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Neverallow rules for ioctl extended permissions will pass in two
cases:
1. If extended permissions exist for the source-target-class set
the test will pass if the neverallow values are excluded.
2. If extended permissions do not exist for the source-target-class
set the test will pass if the ioctl permission is not granted.
Signed-off-by: Jeff Vander Stoep <jeffv@google.com>
Acked-by: Nick Kralevich <nnk@google.com>
Acked-by: Stephen Smalley <sds@tycho.nsa.gov>
The ioctl operations code is being renamed to the more generic
"extended permissions." This commit brings the policy compiler
up to date with the kernel patch.
Signed-off-by: Jeff Vander Stoep <jeffv@google.com>
In Xen on ARM, device tree nodes identified by a path (string) need to
be labeled by the security policy.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
In order to support paths containing spaces or other characters, allow a
quoted string with these characters to be parsed as a path in addition
to the existing unquoted string.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
When the FILESYSTEM token was added to support filesystem names that
start with a digit (e.g. 9p), it was given higher precedence than
NUMBER and therefore all values specified in hex (with 0x prefix)
in policy will incorrectly match FILESYSTEM and yield a syntax error.
This breaks use of iomem ranges in Xen policy and will break ioctl
command ranges in a future SELinux policy version. Switch the
precedence. This does mean that you cannot currently have a filesystem
with a name that happens to be 0x followed by a hexval but hopefully
that isn't an issue.
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
In C, defining a function with () means "any number of parameters", not
"no parameter". Use (void) instead where applicable and add unused
parameters when needed.
Acked-by: Steve Lawrence <slawrence@tresys.com>
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:
