Commit 99fc177b "Add neverallow support for ioctl extended permissions"
first checks to see if the ioctl permission is granted, then checks to
see if the same source/target violates a neverallowed ioctl command.
Unfortunately this does not address the case where the ioctl permission
and extended permissions are granted on different attributes. Example,
the following will incorrectly cause a neverallow violation.
allow untrusted_app self:tcp_socket ioctl;
allowxperm domain domain:tcp_socket unpriv_sock_ioctls;
neverallowxperm untrusted_app domain:tcp_socket ~unpriv_sock_ioctls;
The fix is to enumerate over the source and target attributes when
looking for extended permission violations.
Note: The bug this addresses incorrectly asserts that a violation has
occurred. Actual neverallow violations are always caught.
Signed-off-by: Jeff Vander Stoep <jeffv@google.com>
Tested-by: William Roberts <william.c.roberts@intel.com>
For both neverallow and bounds checking keep neverallow and bounds
failures separate from program faults.
Have secilc exit with an error (and fail to build a binary policy)
when bounds checks fail.
Signed-off-by: James Carter <jwcart2@tycho.nsa.gov>
There are three improvements.
When calling cil_find_matching_avrule_in_ast(), one parameter specifies
whether to return a match of the exact same (not a duplicate) rule.
Since the target passed in is created and not actually in the tree
by making this parameter true an extra comparison can be avoided.
Currently, when printing a bounds violation trace, every match except
for the last one has only the parents of the rule printed. Only the
last rule has both its parents and the actual rule printed. Now the
parents and rule are printed for each match. This has the additional
benefit that if a match is not found (there should always be a match)
a seg fault will not occur.
To reduce the amount of error reporting, only print a trace of a
matching rule if it is different from the previous one.
Signed-off-by: James Carter <jwcart2@tycho.nsa.gov>
An attribute that has no types associated with it should still match
with itself, but ebitmap_match_any() will return false if there are
no bits set in either bitmap. The solution is to check to see if the
two datums passed into cil_type_match_any() are the same. This has
the additional advantage of providing a quick match anytime the
attributes are the same.
Signed-off-by: James Carter <jwcart2@tycho.nsa.gov>
The man page contains 'prce' instead of 'pcre'
Reported-by: Milos Malik <mmalik@redhat.com>
Signed-off-by: Petr Lautrbach <plautrba@redhat.com>
Signed-off-by: James Carter <jwcart2@tycho.nsa.gov>
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>
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 not the same as 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, provide a warning message when converting a policy
package to CIL and the output filename is different than the module
name.
Signed-off-by: James Carter <jwcart2@tycho.nsa.gov>
Other build scripts define -D_GNU_SOURCE. The Android build
system should too.
Fixes the following warning:
external/selinux/libsepol/cil/src/cil_mem.c:109:7: warning: implicit
declaration of function 'vasprintf' is invalid in C99
[-Wimplicit-function-declaration]
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>
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1319338
$ sepolgen-ifgen
/usr/share/selinux/devel/include/contrib/docker.if: Syntax error on line 503 docker_t [type=IDENTIFIER]
/usr/share/selinux/devel/include/roles/unconfineduser.if: Syntax error on line 706 unconfined_t [type=IDENTIFIER]
Signed-off-by: Miroslav Grepl <mgrepl@redhat.com>
During resolution of classcommon statements (cil_resolve_classcommon),
we add the number of class common permissions to the values of the class
permissions. This way, the internal CIL values of the common permission
go from 0 to N, and the values of class permissions start at N+1 (where
N is the number of common permissions). When we reset a class due to
reresolve (cil_reset_class), we must then reverse this process by
subtracting the number of common permissions from the class permission
values.
However, there is a bug when resetting classes in which we subtract the
number of common permissions from the common permissions value rather
than the class permissions value. This means that class permissions
could be too high (since they are not reduced on reset) and common
permissions underflowed (since they are reduced, but should not be).
In most cases, this didn't actually matter since these permission values
aren't used when creating the binary. Additionally, we always access the
permissions via a hash table lookup or map, and then use whatever value
they have to set bits in bitmaps. As long as the bits in the bitmap
match the values, things work as expected. However, the one case where
these values do matter is if you use 'all' in a class permission set. In
this case, we enable bits 0 through number of permissions in a bitmap.
But because our permission values are all mixed up, these enabled bits
do not correspond to the permission values. This results in making it
look like no permissions were set in a class permission set, and the
rule is essentially ignored.
This patch fixes the bug so that the values of class permissions are
properly reset, allowing one to use 'all' in class permission sets in a
policy that reresolves.
Signed-off-by: Steve Lawrence <slawrence@tresys.com>
Signed-off-by: James Carter <jwcart2@tycho.nsa.gov>
Commit 9df498884665d ("libselinux: Mount procfs before checking
/proc/filesystems") changed selinuxfs_exists() to always try
mounting /proc before reading /proc/filesystems. However, this is
unnecessary if /proc is already mounted and can produce avc denials
if the process is not allowed to perform the mount. Check first
to see if /proc is already present and only try the mount if it is not.
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
getpidcon documentation does not specify that a pid of 0 refers to the
current process, and getcon exists specifically to provide this
functionality, and getpidcon(getpid()) would provide it as well.
Disallow pid values <= 0 that may lead to unintended behavior in
userspace object managers.
Signed-off-by: Daniel Cashman <dcashman@android.com>
The selinux_restorecon(3) man page details this function.
It has been built using the work from Android where an SHA1 hash
of the specfiles is held in an extended attribute to enhance
performance. Also contains components from policycoreutils/setfiles.
The utils/selinux_restorecon.c utility demonstrates the functionality.
Signed-off-by: Richard Haines <richard_c_haines@btinternet.com>
Inserting non-ascii characters into the following files:
* file_contexts
* property_contexts
* service_contexts
can cause a failure on labeling but still result in a successful
build.
Hard error on non-ascii characters with:
<path>: line 229 error due to: Non-ASCII characters found
Signed-off-by: William Roberts <william.c.roberts@intel.com>
libsemanage/tests/Makefile currently overwrites CFLAGS and LDFLAGS
contents. This makes building with custom flags (e.g. with address
sanitizer) harder. Append flags to these variables instead.
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
sepolicy Makefile overwrites CFLAGS value, which prevents compiling its
Python module with custom compilation flags. Modify it to append flags
to CFLAGS instead, like other policycoreutils programs do.
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
Variable policy is both a global variable and a parameter to some
functions in policycoreutils/sepolicy/search.c. This makes the building
fail when using -Wshadow -Werror compilation flags.
Fix this by renaming the global variable global_policy. This does not
change the API of the Python module.
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
clang warns about variables which are used in a function body even
though they were marked __attribute__((unused)). For example:
interfaces.c:129:2: error: 'handle' was marked unused but was used
[-Werror,-Wused-but-marked-unused]
handle = NULL;
^
interfaces.c:233:2: error: 'handle' was marked unused but was used
[-Werror,-Wused-but-marked-unused]
handle = NULL;
^
Remove these warnings either by removing meaningless assigments or by
removing the attribute.
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
When building newrole with gcc 5.3.0 and some warning flags, the
compiler reports:
newrole.c:77:33: error: "NAMESPACE_PRIV" is not defined [-Werror=undef]
#if defined(AUDIT_LOG_PRIV) || (NAMESPACE_PRIV)
^
Indeed, "defined" is missing here. This nevertheless worked so far
because when NAMESPACE_PRIV was selected in the Makefile, newrole.c was
compiled with "-DNAMESPACE_PRIV", which defined NAMESPACE_PRIV to 1.
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
Some refpolicy interfaces use:
* "$" character in paths, for example in kernel/selinux.if:
genfscon selinuxfs /booleans/$2 gen_context(system_u:object_r:$1,s0)
* empty members in ifelse statement, for example in system/init.if:
ifelse(`$5',`',`',`
...
')
Modify sepolgen/refparser grammar accordingly.
This fixes the following syntax errors reported by sepolgen-ifgen:
/usr/share/selinux/refpolicy/include/kernel/selinux.if: Syntax error
on line 43 gen_context [type=GEN_CONTEXT]
/usr/share/selinux/refpolicy/include/system/init.if: Syntax error on
line 1416 ' [type=SQUOTE]
/usr/share/selinux/refpolicy/include/system/init.if: Syntax error on
line 1422 ' [type=SQUOTE]
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
Since Python 3.3, dictionary hashes are randomized and iterating over
them is no longer deterministic. This makes it difficult to compare
outputs of sepolgen-ifgen command.
Make sepolgen-ifgen deterministic again with Python>=3.3 by always
sorting the dictonaries and sets which are used to produce output.
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
In semanage_direct_set_module_info() and semanage_direct_list_all()
functions, when modinfo_tmp variable gets initialized, a branch to
"cleanup" label may have already been taken. This leads to this
variable being possibly used uninitialized in these functions.
This is reported by clang:
direct_api.c:2491:41: error: variable 'modinfo_tmp' may be
uninitialized when used here [-Werror,-Wconditional-uninitialized]
ret = semanage_module_info_destroy(sh, modinfo_tmp);
^~~~~~~~~~~
direct_api.c:2334:2: note: variable 'modinfo_tmp' is declared here
semanage_module_info_t *modinfo_tmp = NULL;
^
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
In semanage_direct_commit() error path, bools_modified can be used in a
if statement without being initialized (when a "goto cleanup" is taken
early). clang warns about this bug:
direct_api.c:1441:18: error: variable 'bools_modified' may be
uninitialized when used here [-Werror,-Wconditional-uninitialized]
if (modified || bools_modified) {
^~~~~~~~~~~~~~
direct_api.c:1087:48: note: initialize the variable 'bools_modified'
to silence this warning
preserve_tunables_modified, bools_modified,
^
= 0
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
clang warns that __cil_permx_to_sepol_class_perms() return value, rc,
may be unitialized:
../cil/src/cil_binary.c:4188:9: error: variable 'rc' may be
uninitialized when used here [-Werror,-Wconditional-uninitialized]
return rc;
^~
../cil/src/cil_binary.c:4148:8: note: initialize the variable 'rc'
to silence this warning
int rc;
^
= 0
This theoretically happens when cil_expand_class(permx->obj) returns an
empty list.
Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
