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>
Originally checkmodule stated that it wrote to the input file instead of
to the output file.
Reported-By: Milos Malik <mmalik@redhat.com>
Signed-off-by: Petr Lautrbach <plautrba@redhat.com>
As per discussion in https://android-review.googlesource.com/#/c/221980,
we should be using #ifdef __APPLE__ rather than our own custom-defined
DARWIN for building on MacOS X.
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Commit 3895fbbe0c ("selinux: Add support
for portcon dccp protocol") added support for the (portcon dccp ..)
statement. This fix will allow policy to be built on platforms
(see [1]) that do not have DCCP support by defining the IANA
assigned IP Protocol Number 33 to IPPROTO_DCCP.
[1] https://android-review.googlesource.com/#/c/219568/
Signed-off-by: Richard Haines <richard_c_haines@btinternet.com>
Since CIL treats files as modules and does not have a separate
module statement it can cause confusion when a Refpolicy module
has a name that is different than its base filename because older
SELinux userspaces will refer to the module by its module name while
a CIL-based userspace will refer to it by its filename.
Because of this, have checkmodule fail when compiling a module and
the output base filename is different than the module name.
Signed-off-by: James Carter <jwcart2@tycho.nsa.gov>
This adds CIL and checkpolicy support for the (portcon dccp ...)
statement. The kernel already handles name_bind and name_connect
permissions for the dccp_socket class.
Signed-off-by: Richard Haines <richard_c_haines@btinternet.com>
Signed-off-by: James Carter <jwcart2@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>
checkpolicy was directly assigning type sets rather than using
type_set_cpy() and therefore creating pointer aliases to the
same type set from multiple filename-based type transition rules
if they specified multiple classes. This would then yield a double
free when destroying the rules afterward and a segmentation fault.
Fix it to use type_set_cpy().
Reported-by: William C Roberts <william.c.roberts@intel.com>
Signed-off-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>
Fixes compiler warnings all similar to the following:
host C: checkpolicy <= external/selinux/checkpolicy/policy_define.c
external/selinux/checkpolicy/policy_define.c:1572:2: warning: comparison of integers of different signs: 'int' and 'uint32_t' (aka 'unsigned int') [-Wsign-compare]
ebitmap_for_each_bit(&tclasses, node, i) {
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
external/selinux/checkpolicy/../libsepol/include/sepol/policydb/ebitmap.h:76:39: note: expanded from macro 'ebitmap_for_each_bit'
for (bit = ebitmap_start(e, &n); bit < ebitmap_length(e); bit = ebitmap_next(&n, bit)) \
^ ~~~~~~~~~~~~~~~~~
Signed-off-by: Nick Kralevich <nnk@google.com>
--089e013a1a2abb8ecf0518469d04
Content-Type: text/plain; charset=UTF-8
assert() only prevents -Wreturn-type from firing if asserts are
enabled. Use abort() so we don't do unexpected things even if we use
-UNDEBUG.
<div dir="ltr"><div>assert() only prevents -Wreturn-type from firing if asserts are</div><div>enabled. Use abort() so we don't do unexpected things even if we use</div><div>-UNDEBUG.</div></div>
From b53ad041da Mon Sep 17 00:00:00 2001
From: Dan Albert <danalbert@google.com>
Date: Wed, 10 Jun 2015 17:01:23 -0700
Subject: [PATCH] Fix -Wreturn-type issues.
To: selinux@tycho.nsa.gov
Cc: nnk@google.com,
sds@tycho.nsa.gov
assert() only prevents -Wreturn-type from firing if asserts are
enabled. Use abort() so we don't do unexpected things even if we use
-UNDEBUG.
Also drop expanding of rules; just display the rules in their
original form. I think expansion was a relic of an older policy
version where we did not preserve attributes in the kernel policy.
In any event, it seems more useful to display the rules unmodified.
Change-Id: I85095a35cfb48138cd9cf01cde6dd0330e342c61
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Adds support for new policy statements whitelisting individual ioctl
commands. Ioctls provide many of the operations necessary for driver control.
The typical driver supports a device specific set of operations accessible
by the ioctl system call and specified by the command argument. SELinux
provides per operation access control to many system operations e.g. chown,
kill, setuid, ipc_lock, etc. Ioclts on the other hand are granted on a per
file descriptor basis using the ioctl permission, meaning that the set of
operations provided by the driver are granted on an all-or-nothing basis.
In some cases this may be acceptable, but often the same driver provides a
large and diverse set of operations such as benign and necessary functionality
as well as dangerous capabilities or access to system information that should
be restricted.
Example policy:
allow <source> <target>:<class> { 0x8900-0x8905 0x8910 }
auditallow <source> <target>:<class> 0x8901
The ioctl permission is still required in order to make an ioctl call. If no
individual ioctl commands are specified, only the ioctl permission is
checked by the kernel - i.e. status quo. This allows ioctl whitelisting to
done in a targeted manner, protecting desired drivers without requiring every
ioctl command to be known and specified before use and otherwise allowing
existing policy to be used as-is.
This only implements ioctl whitelisting support for monolithic kernel policies
built via checkpolicy. Support for modules and CIL remains to be done.
Bug: 19419509
Change-Id: I198e8c9279b94d8ce4ae5625018daa99577ee970
Signed-off-by: Jeff Vander Stoep <jeffv@google.com>
Acked-by: Stephen Smalley <sds@tycho.nsa.gov>
Add support to checkpolicy and checkmodule for generating CIL as their
output.
Add new options "-C" and "--cil" to specify CIL as the output format.
Signed-off-by: James Carter <jwcart2@tycho.nsa.gov>
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>
This expands IOMEMCON device context entries to 64 bits. This change is
required to support static I/O memory range labeling for systems with
over 16TB of physical address space. The policy version number change
is shared with the next patch.
While this makes no changes to SELinux policy, a new SELinux policy
compatibility entry was added in order to avoid breaking compilation of
an SELinux policy without explicitly specifying the policy version.
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>
Our build system compiles flex/bison as C++ rather than C, but a few
projects add `-x c` to their flags, forcing the compiler to compile
them as C. This causes the compiler to reject the global C++ standard
flag, so we need to explicitly provide a C standard flag to override
it.
Bug: 18466763
Change-Id: I49a6aeecf4abc563bd77127778b6d214e3851037
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Since strtol(3) doesn't clear errno on success, anything that sets
errno prior to this call will make it look like the call failed. This
happens when built with ASAN.
Signed-off-by: Dan Albert <danalbert@google.com>
Acked-by: Steve Lawrence <slawrence@tresys.com>
