selinuxproject / selinux Goto Github PK

Currently the sandbox manual page wrongly describes at least two of the contexts

sandbox_x_t \-  Printer Ports

sandbox_net_t   \-  All network ports

actually sandbox_x_t is for X windows, sandbox_net_t seems to block outgoing connections and there is an additional sandbox_net_client_t which seems to allow outgoing network connections.

N.B. The definition of the sandbox seems clearest in this selinux manual page. Confirmation that sandbox_net_t isn't meant to give full network access can be gleaned from this bugzilla ticket

When attempting to utilize the built in busybox support for SELinux, which relies on libselinux, it was not allowing users to log in, failing to get SID for user. I am brand new to SELinux so I could be wrong, but after much debugging it appears to me that the get_default_context() API that busybox is using requires an SELinux user to be passed in, not a regular Linux username. Looking at the man page for this API, it is not clear to me what kind of user is expected to be passed in. Could the documentation please be updated to specify this, if I am correct in believing that it is expecting to receive SELinux users only? busybox is passing in the login username (regular Linux user account), so I updated busybox to call getseuserbyname() before the call to get_default_context() so it passes in the seuser and now it is working. This is similar to what PAM library appears to do for a similar call to get a default content. If busybox implementation is incorrect, I can only assume it is because of the lack of clarity in the documentation. Or perhaps libselinux used to do that username translation inside get_default_context()?

Thanks for looking.

I am not sure if this is an code issue or just wrong build environment setup, but i get the same error in Ubuntu 18.04 and Fedora 28 running on ARM device. How to fix makefile?

cc -O2 -Werror -Wall -Wextra -Wmissing-format-attribute -Wmissing-noreturn -Wpointer-arith -Wshadow -Wstrict-prototypes -Wundef -Wunused -Wwrite-strings -I/home/fedora/obj/usr/include -I. -I../include -D_GNU_SOURCE -I../cil/include -fPIC -c -o ibpkeys.o ibpkeys.c In file included from ibpkeys.c:4: ibpkeys.c: In function 'sepol_ibpkey_query': ibpkeys.c:179:14: error: format '%lx' expects argument of type 'long unsigned int', but argument 4 has type 'uint64_t' {aka 'long long unsigned int'} [-Werror=format=] ERR(handle, "could not query ibpkey subnet prefix: %#lx range %u - %u exists", ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ subnet_prefix, low, high); ~~~~~~~~~~~~~ debug.h:46:15: note: in definition of macro 'msg_write' _sepol_h, __VA_ARGS__); \ ^~~~~~~~~~~ ibpkeys.c:179:2: note: in expansion of macro 'ERR' ERR(handle, "could not query ibpkey subnet prefix: %#lx range %u - %u exists", ^~~ ibpkeys.c: In function 'sepol_ibpkey_modify': ibpkeys.c:206:14: error: format '%lx' expects argument of type 'long unsigned int', but argument 4 has type 'uint64_t' {aka 'long long unsigned int'} [-Werror=format=] ERR(handle, "could not load ibpkey subnet prefix: %#lx range %u - %u exists", ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ subnet_prefix, low, high); ~~~~~~~~~~~~~ debug.h:46:15: note: in definition of macro 'msg_write' _sepol_h, __VA_ARGS__); \ ^~~~~~~~~~~ ibpkeys.c:206:2: note: in expansion of macro 'ERR' ERR(handle, "could not load ibpkey subnet prefix: %#lx range %u - %u exists", ^~~ cc1: all warnings being treated as errors make[2]: *** [Makefile:76: ibpkeys.o] Error 1 make[2]: Leaving directory '/home/fedora/src/selinux/libsepol/src' make[1]: *** [Makefile:6: all] Error 2 make[1]: Leaving directory '/home/fedora/src/selinux/libsepol' make: *** [Makefile:34: all] Error 1 [fedora@localhost selinux]$

I'd like suggest a new SELinux policy language feature to constrain attribute assignment.
In the reference policy for example, there are the attributes auth_file_type and non_auth_file_type, which should be contradictory, but can be easily messed up by

type example_t;
files_auth_file(example_t)
files_config_file(example_t)

While on it, a type may also be constrained to hold one attribute of a set:

nevertypeattribute auth_file_type non_auth_file_type; # make these attributes contradictory
nevertypeattribute domain file_type filesystem_type port_type; # make these attributes exclusive

There are use cases where neither the SELinux user nor role are used at all (e.g. Android, which defines a single user and a single role), and even in Linux distributions, you really only need one or the other, not both. The SELinux user was originally envisioned to be the actual Linux username, but that was supplanted by the seusers mapping, making it more akin to a role. In any event, it should be configurable in policy whether we include the user and/or role and if not, then the relevant policy components and security context fields should just go away entirely. We're presently wasting space in security contexts for them, mostly always for files (unless using RBACSEP) and even to some degree for processes.

libselinux has legacy interfaces and compatibility code that are still in use by some external applications. We need to identify all such users and update them to use the newer interfaces, e.g. replace calls to matchpathcon interfaces with calls to selabel interfaces, replace most if not all SELinux userspace permission checks (security_compute_av, avc_has_perm) with calls to selinux_check_access, etc. Then maybe someday we can actually get rid of the legacy stuff upstream.

Libsepol uses cdefs.h which is a internal glibc header.
This header is not intended to be used by any program and will cause
compiling against musl (and possibly other c libraries) to fail.
This patch fixed this issue and replaces all references of
#include <sys/cdefs.h> and __BEGIN/END_DECLS with the appropriate #ifdefs.

libsepol-remove-cdefs-references.patch.zip

Unfortunately we cannot presently do a simple cmp of a policy file in the filesystem and /sys/fs/selinux/policy because there are differences in the binary image even though they are semantically identical. While sediff can be used here, it is not complete in its coverage and is an independent tool that could get out of sync anyway; it would be better if we could get the two files identical and comparable via cmp. I think I know why they currently differ (range transition order). The kernel has been enhanced over time to load the range transition rules into a hashtab with a deterministic order for the hash chains; we should do likewise in libsepol/checkpolicy so that they will match. There may still be other potential differences, e.g. if the kernel does not support the policy version of the policy file and load_policy/libsepol downgrade it in memory for loading, but this will be less common, or possibly differences in ebitmaps due to the ebitmap optimization work in the kernel (but this could also be lifted into libsepol and included in the policy format).

It seems https://lgtm.com/projects/g/SELinuxProject/selinux/ does not check the c code.
I am not too familiar with the service, but maybe a configuration file is needed.

Hello
I receive the following error when attempting to run the build script.

src/basic/errno-from-name.h:143:1: error: conflicting types for ‘lookup_errno’
 lookup_errno (register const char *str, register size_t len)
 ^~~~~~~~~~~~
src/basic/errno-list.c:25:33: note: previous declaration of ‘lookup_errno’ was here
 static const struct errno_name* lookup_errno(register const char *str,
                                 ^~~~~~~~~~~~
make[2]: *** [Makefile:15926: src/basic/libbasic_la-errno-list.lo] Error 1
make[1]: *** [Makefile:21958: all-recursive] Error 1
make: *** [Makefile:9898: all] Error 2
==> ERROR: A failure occurred in build().
    Aborting...

I am trying to install SELinux on a ArchLinux VM. How can I resolve this?

[email protected] fails without further notification of the nature of the error. As far as I can tell, the red hat SELinux User's and Administrator's Guide does not mention this migration service.

OS: Centos7 3.10.0-514.6.1.el7.x86_64

EDIT: attempting to run /usr/libexec/selinux/selinux-policy-migrate-local-changes.sh directly results in...

/usr/libexec/selinux/selinux-policy-migrate-local-changes.sh: line 58: /etc/selinux//modules/active/README.migrated: No such file or directory

Service error messages:

[email protected] - Migrate local SELinux policy changes from the old store structure to the new structure
Loaded: loaded (/usr/lib/systemd/system/basic.target.wants/../[email protected]; static; vendor preset: disabled)
Active: failed (Result: exit-code) since Tue 2017-04-18 23:11:25 UTC; 41min ago
Main PID: 589 (code=exited, status=208/STDIN)

Apr 18 23:11:25 user5411-centos7 systemd[1]: Starting Migrate local SELinux policy changes from the old store structure to the new structure...
Apr 18 23:11:25 user5411-centos7 systemd[589]: Failed at step STDIN spawning /usr/libexec/selinux/selinux-policy-migrate-local-changes.sh: Inappropriate ioctl for device
Apr 18 23:11:25 user5411-centos7 systemd[1]: [email protected]: main process exited, code=exited, status=208/STDIN
Apr 18 23:11:25 user5411-centos7 systemd[1]: Failed to start Migrate local SELinux policy changes from the old store structure to the new structure.
Apr 18 23:11:25 user5411-centos7 systemd[1]: Unit [email protected] entered failed state.
Apr 18 23:11:25 user5411-centos7 systemd[1]: [email protected] failed.

There is no /var/lib/selinux directory on the system... a likely component of the error.

/etc/selinux
├── tmp
├── targeted
│   ├── seusers
│   ├── setrans.conf
│   ├── semanage.trans.LOCK
│   ├── semanage.read.LOCK
│   ├── policy
│   │   └── policy.30
│   ├── modules
│   │   └── active
│   │   └── modules
│   ├── logins
│   ├── contexts
│   │   ├── x_contexts
│   │   ├── virtual_image_context
│   │   ├── virtual_domain_context
│   │   ├── users
│   │   │   ├── xguest_u
│   │   │   ├── user_u
│   │   │   ├── unconfined_u
│   │   │   ├── sysadm_u
│   │   │   ├── staff_u
│   │   │   ├── root
│   │   │   └── guest_u
│   │   ├── userhelper_context
│   │   ├── systemd_contexts
│   │   ├── snapperd_contexts
│   │   ├── sepgsql_contexts
│   │   ├── securetty_types
│   │   ├── removable_context
│   │   ├── lxc_contexts
│   │   ├── initrc_context
│   │   ├── files
│   │   │   ├── media
│   │   │   ├── file_contexts.subs_dist
│   │   │   ├── file_contexts.subs
│   │   │   ├── file_contexts.homedirs.bin
│   │   │   ├── file_contexts.homedirs
│   │   │   ├── file_contexts.bin
│   │   │   └── file_contexts
│   │   ├── failsafe_context
│   │   ├── default_type
│   │   ├── default_contexts
│   │   ├── dbus_contexts
│   │   └── customizable_types
│   ├── booleans.subs_dist
│   └── active [error opening dir]
├── semanage.conf
├── final [error opening dir]
└── config

At present we can only specify an individual type as the child in a typebounds statement.
This makes it difficult to specify that many types are bounded a single parent type.
Update libsepol/checkpolicy to support specifying an attribute for the child type, and either
update the policy file and kernel to also support this (i.e. new policy version) or have libsepol expand
the rules at build time.

The source of tools in the page https://github.com/SELinuxProject/selinux/wiki/Tools is out off date base on 2.7 release, could anyone update it?

Since policies are mostly auto-generating large numbers of categories via macros and defining each level as being authorized for all categories and defining various initial security contexts with all categories set, the category representation in the policy ends up being larger than needed. It would be helpful to allow the policy to just specify the number of categories and not need to store the c0, c1, ... strings in the policy when we do not want human-meaningful names in the kernel categories, and to provide an efficient ebitmap representation of all-categories-set without actually generating a large bitmap with all bits set. This can be done at multiple levels, from just changing the ebitmap representation in the policy (requiring changes to libsepol and the kernel and a new policy version) to also extending the policy language and security server to support implicit category definition with only the number of categories being specified.
Also consider a more efficient representation in security context strings, e.g. a bitmap string format ala 0xfffffe0d..., to reduce the pressure on passing security context strings across often page-size-limited boundaries for /proc/pid and selinuxfs and reduce memory consumption. (However, this may not prove to be a win, since the current format is more efficient for sparse bitmaps and allows compact representation of a series of consecutive categories via the cN.cM notation; probably the major corner case at present is when you have a bitmap with every other bit set).

audit2allow is pretty dumb, and for better or worse many users and developers rely on it to produce policy. Enhance it to support automatic generation/suggestion of new domains/types rather than only producing allow rules within the current domain/type space, to provide better assistance with MLS or other constraint denials, to support other macros/interfaces besides refpolicy (e.g. Android), and to help guide the user in making sound choices (e.g. don't allow dac_override if you only need dac_read_search).

I have this bug report written, I likely can't do anything further with it for a few days.

In particular, this issue will be annoying when fixfiles onboot is invoked.

"Good" version: policycoreutils-2.5-19.fc25.x86_64:

Relabeling / /boot /dev /dev/hugepages /dev/mqueue /dev/pts /dev/shm /home /run /run/user/1000 /run/user/1001 /run/user/42 /sys /sys/fs/pstore /sys/kernel/debug /tmp
100.0%
Cleaning up labels on /tmp

"Bad" version: 20161014-199-gd66c54e

• built according to README
• hacked fixfiles script to use ~alan-sysop/obj/sbin/setfiles
• sudo sh -c 'LD_LIBRARY_PATH=~alan-sysop/obj/lib sh ./policycoreutils/scripts/fixfiles restore'

Result: My impression from watching fatrace, was that the percentage indicator only applied to the first filesystem /. Once fixfiles got to /home, it was just printing asterixes. /home can potentially have many more files than /.

Relabeling / /boot /dev /dev/hugepages /dev/mqueue /dev/pts /dev/shm /home /run /run/user/1000 /run/user/1001 /run/user/42 /sys /sys/fs/pstore /sys/kernel/debug /tmp
100.0%
100.0%
100.0%

*




******************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************
*



********************************

See https://bugzilla.redhat.com/show_bug.cgi?id=678577

When $(DESTDIR) is defined, the $(PYSITEDIR) ends up with a double
absolute path. (In the normal case with $(DESTDIR) not defined,
site.getsitepackages()[0] already results in an absolute path)

setfiles will detect and try to resolve situations where there are multiple hard links to the same file that would yield a different security context. restorecon does not. With the logic moved into libselinux selinux_restorecon(), we ought to support it generically there. The current logic however assumes that SELINUX_RESTORECON_ADD_ASSOC is only passed if SELINUX_RESTORECON_XDEV is also passed, since it only saves and compares the inode numbers (not the device numbers) and since it creates/destroys the filespec mapping on each call. So, to support this for restorecon, we would need to augment struct file_spec with the device number, save and compare the (dev, ino) pairs when checking for a conflict, and then restorecon could be changed to pass SELINUX_RESTORECON_ADD_ASSOC by default too (if desired) or at least if some new option was set.

Hi,

It seems that the policycoreutils/hll/pp/Makefile does not honor CPPFLAGS passed at build time. This is needed form some hardening functionalities

The current implementation of sepol_av_to_string does not NULL-terminate avbuf if av == 0 or if none of the bits match a permission.

char *sepol_av_to_string(policydb_t * policydbp, uint32_t tclass,
			 sepol_access_vector_t av)
{
	// ...
	static char avbuf[1024];
	// ...
	for (i = 0; i < cladatum->permissions.nprim; i++) {
		if (av & (1 << i)) {
			// ...
			if (perm) {
				len =
				    snprintf(p, sizeof(avbuf) - avlen, " %s",
					     perm);
				// ...
			}
		}
	}

	return avbuf;
}

This may not be an issue if av is validated elsewhere. I'm personally using libsepol to disable all the auditdeny/dontaudit rules by removing the permission bits (ie. av_cur->datum.data = ~0U) and ran into this issue trying to print the result.

EDIT: The buffer may be NULL-terminated since static arrays are zero-initialized, but with the inputs mentioned above, the result is still incorrect.

Hi,

I'm packaging libsepol for Arch Linux and as this distro is using /usr/lib for all libraries, I'm using this command line to install libsepol:

make DESTDIR="${pkgdir}" LIBDIR="${pkgdir}"/usr/lib SHLIBDIR="${pkgdir}"/usr/lib install

However this creates a broken symlink, as /usr/lib/libsepol.so is linked to ../../lib/libsepol.so.1 which does not exists in the temporary build directory.

This symlink is created by https://github.com/SELinuxProject/selinux/blob/libsepol-2.4-rc3/libsepol/src/Makefile#L73 :

cd $(LIBDIR) && ln -sf ../../`basename $(SHLIBDIR)`/$(LIBSO) $(TARGET)

... which is expanded to:

cd /tmp/makepkg-user/libsepol/pkg/libsepol/usr/lib && ln -sf ../../`basename /tmp/makepkg-user/libsepol/pkg/libsepol/usr/lib`/libsepol.so.1 libsepol.so

... which is buggy.

A possible solution consists in replacing the command in the Makefile with ln -sf --relative $(SHLIBDIR)/$(LIBSO) $(LIBDIR)/$(TARGET), available since coreutils-8.16 (according to http://savannah.gnu.org/forum/forum.php?forum_id=7170).

Could you please do this before the next release, for all libraries in this project?

Currently they are only supported in monolithic policy and CIL modules.
Never implemented in the binary module format.

The semanage tool crashes on systems without installed policies:

# semanage
Traceback (most recent call last):
  File "/usr/sbin/semanage", line 28, in <module>
    import seobject
  File "/usr/lib/python3.4/site-packages/seobject.py", line 1039, in <module>
    class portRecords(semanageRecords):
  File "/usr/lib/python3.4/site-packages/seobject.py", line 1041, in portRecords
    valid_types = list(list(sepolicy.info(sepolicy.ATTRIBUTE, "port_type"))[0]["types"])
  File "/usr/lib/python3.4/site-packages/sepolicy/__init__.py", line 196, in <genexpr>
    return ({
  File "/usr/lib/python3.4/site-packages/setools/typeattrquery.py", line 65, in results
    for attr in self.policy.typeattributes():
AttributeError: 'NoneType' object has no attribute 'typeattributes'

This is caused by sepol (the python module) setting the global _pol variable to None – something setools.TypeAttributeQuery can't deal with.

platform details:

python3-modules used with python-3.4.3
distribution: mer
libselinux/ libsepol/ libsemanage/ policycoreutils: v2.7
python3-setools: 4.1.1

disclaimer: policycoreutils and setools are customly packaged, this is a possible (but unlikely) error source

The libselinux library fails to build on the Blackfin architecture, with the following error message:

mapping.lo: In function `_selinux_set_mapping':
mapping.c:(.text+0x25a): undefined reference to `_avc_reset'
callbacks.lo: In function `_default_selinux_validate':
callbacks.c:(.text+0x82): undefined reference to `_security_check_context'
callbacks.lo: In function `_default_selinux_log':
callbacks.c:(.text+0x92): undefined reference to `_is_selinux_enabled'
label_media.lo: In function `_selabel_media_init':
label_media.c:(.text+0xf2): undefined reference to `_selinux_media_context_path'
label_file.lo: In function `_init':
label_file.c:(.text+0xa24): undefined reference to `_selinux_file_context_subs_dist_path'
label_file.c:(.text+0xa38): undefined reference to `_selinux_file_context_subs_path'
label_file.c:(.text+0xa4c): undefined reference to `_selinux_file_context_path'
label.lo: In function `_selabel_lookup_common':
label.c:(.text+0x172): undefined reference to `_selinux_raw_to_trans_context'
label_db.lo: In function `_selabel_db_init':
label_db.c:(.text+0xe4): undefined reference to `_selinux_sepgsql_context_path'
sestatus.lo: In function `_selinux_status_open':
sestatus.c:(.text+0x17e): undefined reference to `_security_getenforce'
sestatus.lo: In function `_selinux_status_deny_unknown':
sestatus.c:(.text+0x214): undefined reference to `_security_deny_unknown'
label_x.lo: In function `_selabel_x_init':
label_x.c:(.text+0xee): undefined reference to `_selinux_x_context_path'
collect2: ld returned 1 exit status
Makefile:119: recipe for target 'libselinux.so.1' failed
make[2]: *** [libselinux.so.1] Error 1

This is due to the fact that Blackfin has a special handling of symbols: a symbol called foo in C is called _foo in assembly. This apparently defeats the hidden_ref and hidden_proto logic in dso.h, which doesn't have explicit support for the Blackfin architecture. I tried a bit to change the assembly code to cope with the Blackfin specificities, but didn't manage to get something working. So far, the only solution I found is to simply not use this logic to hide symbols:

diff --git a/libselinux/src/dso.h b/libselinux/src/dso.h
index 12c3d11..f21d088 100644
--- a/libselinux/src/dso.h
+++ b/libselinux/src/dso.h
@@ -1,7 +1,7 @@
 #ifndef _SELINUX_DSO_H
 #define _SELINUX_DSO_H 1

-#ifdef SHARED
+#if defined(SHARED) && !defined(__bfin__)
 # define hidden __attribute__ ((visibility ("hidden")))
 # define hidden_proto(fct) __hidden_proto (fct, fct##_internal)
 # define __hidden_proto(fct, internal) \

But a real solution would be more appropriate.

Hello,
Can you please indicates me how to install correctly selinux on ubuntu 16.10. I can compile it correctly from the source but then I don't how how to create a the configuration file with the minimal policy so I can have a correct running system.
Thanks in advance

Particularly showed requirements are shifted by one index.

cat > module1.te << EOF
module module1 1.0;
require {
        type bin_t;
}
type module1_t;
EOF
cat > module2.te << EOF
module module2 1.0;
require {
        type bin_t;
}
type module2_t;
EOF
cat > module3.te << EOF
module module3 1.0;
require {
        type module1_t;
}
type module3_t;
EOF
cat > module4.te << EOF
module module4 1.0;
require {
        type module2_t;
}
type module4_t;
EOF
cat > module5.te << EOF
module module5 1.0;
require {
        type module1_t;
        type module4_t;
}
type module5_t;
EOF
cat > module6.te << EOF
module module6 1.0;
require {
        type module3_t;
        type module4_t;
}
type module6_t;
EOF
make -f /usr/share/selinux/devel/Makefile
semodule -E base

semodule_deps base.pp module1.pp module2.pp module3.pp module4.pp module5.pp module6.pp
module: module1
        [no dependencies]
module: module2
        [no dependencies]
module: module3
        module2
module: module4
        module3
module: module5
        module2
        module5
module: module6
        module4
        module5
}

Moreover there is } at the end.

I have taken a quick look at the code but have not been able to identify the buggy part. The output seems to be simple enough and sane so I suspect the generate_requires function.

With the transition to CIL, we would like to move away from using binary policy modules/packages; they merely add overhead in time and space and create a maintenance/development burden when adding new features. There is already one SELinux feature that is not even supported in binary policy modules (xperms). Policies that are written and maintained directly in CIL do not have this problem, but CIL was designed to be an intermediate language not a language for humans and is not IMHO as human-friendly as .te files, plus there are many users already familiar with (and many existing policy modules written in) .te file syntax. Monolithic policies can already be compiled directly to CIL via checkpolicy -C, which is the approach used for Android. However we do not have a good solution for modular refpolicy-based policies in Linux distributions; those are still being compiled to binary policy modules/packages. libsemanage already supports adding new high level languages via /usr/libexec/selinux/hll; we just need one that handles source policy (.te file + .fc file concatenated or otherwise packaged together in some way). The converter would need to run m4 with all of the system definitions and headers over the source first, and then parse the result and output a CIL module. This differs from the current convertors for pp files or a complete policy.conf because those already have all macros expanded and are either already in policydb format or are compiled first to a policydb before generating CIL.

Would an approach using sync's like the suggestion here be viable?
http://buildroot-busybox.2317881.n4.nabble.com/PATCH-docs-manual-gcc-4-4-is-the-lowest-we-are-known-to-work-with-tp200075p200254.html

I am an Android developer, and the AOSP guidelines regarding SELinux here suggest the use of the audit2allow tool, which I believe originates from this repository. My sample run went something like this :

$ adb shell su root dmesg | audit2allow -p sepolicy 
libsepol.policydb_read: policydb version 30 does not match my version range 15-29
invalid binary policy sepolicy

Is there any way I can work around this? It'd be a real bother to build a sepolicy with policydb version 29 to begin testing and fixing denials

What did you do?

cd
sandbox -X -i myfile2.doc xdg-open myfile2.doc

What happened?
xdg-open: no permission to read file '/home/mikedlr/myfile2.doc'

What did you expect to happen?
Sandbox should open the file - I'd normally expect that if I am allowed to use a file, then I should be allowed to use it in a sandbox which should always be a more restricted environment than the one that I am currently in.

Any other information:

$ ls -Z myfile2.doc 
unconfined_u:object_r:user_home_t:s0 myfile2.doc

This is running on a fedora23 more or less default install. The package with the failing sandbox is policycoreutils-2.4-21.fc23.x86_64

I'm putting this in as an upstream report of https://bugzilla.redhat.com//show_bug.cgi?id=1317046 for use in a pull request, I intend to attempt to patch this and then, succeed or fail, report the situation to the mailing list.

Currently, if one wants to use SELinux in an embedded filing system, there is no real right way to set the default contexts.

Take BuildRoot (https://buildroot.org/) for example. It has everything needed to build and run a system with SELinux. However, the big hangup is setting the filesystem contexts. Currently, the only solution I have found is to run the generated root filing system in a sandbox environment (qemu-system-arm) and run restorecon there, but it would be wonderful if there were a more natural way to do so.

Would it be possible to add the ability for restorecon to point to a different root target path/selinux policy? I can't immediately think of a reason why not, and it would go a long way to having the embedded community adopt SELinux.

Hello.

A suspicious integer overflow is found in libselinux/src/compute_user.c : 54.
The source code is here. (https://github.com/SELinuxProject/selinux/blob/master/libselinux/src/compute_user.c#L54)

If variable "nel" can be crafted as 0xffff ffff, the integer addition at line 54 would overflow to 0, leading to no memory space allocated. This would further lead to buffer overflow at line 62 in a loop. Note that vulnerable "nel" is read from a file "selinux_mnt/user", following the path, i.e. line 27, line 28, line 45 and line 49.

Since I'm not an expert in the source code of libselinux, I'm not sure whether "nel" can be assigned with that very big integer (0xffff ffff). If so, this issue is a severe bug definitely. If not, it is a false positive and please ignore it.

Thanks a lot.

It would be nice, if sestatus shows whether neverallow rules are checked

IIUC, various stateless system / factory reset models, including that of systemd, expect to be able to flush /var and /etc in order to reset to the original pristine OS state stored in a read-only /usr partition. To make this work well with SELinux, we would need to have libselinux and libsemanage fallback to a new /usr/selinux directory tree if there is no /etc/selinux or /var/lib/selinux, and optimally we would only store new and modified file in /etc/selinux or /var/lib/selinux, not any policy files that we are using unchanged from the distro (so e.g. we might end up linking some policy modules from /usr/selinux with others in /var/lib/selinux or /etc/selinux to produce the final policy that we install to /etc/selinux).

I get the following error when using command: make DESTDIR=~/obj install install-pywrap

utilities.c:29:18: fatal error: ustr.h: No such file or directory
compilation terminated.
Makefile:113: recipe for target 'utilities.o' failed
make[2]: *** [utilities.o] Error 1

audit2why does not understand type bounds failures because libsepol sepol_compute_av_reason() has not been updated to support it. More fundamentally, the libsepol context_struct_compute_av() logic has not been updated in some time to reflect changes to the kernel logic, including the bounding logic.

Hi,

It seems that in the interface.py file of sepolicy, the code calls segenxml.py from the refpolicy with python2.

Looking at segenxml.py it seems that the shebang is defined with python3, I guess that the invocation should use python3 as well

https://github.com/SELinuxProject/selinux/blob/master/python/sepolicy/sepolicy/interface.py#L201

I am using CentOS 7, policycoreutils 2.5.

Whenever a custom fcontext rule with file type "socket" is added, semanage fcontext -E stops working until the rule is removed. This is particularly unfortunate for me as it breaks Puppet which relies on the export functionality to determine whether a rule needs to be added or not.

Steps To Reproduce:

1. Run semanage fcontext -E
   → output is correct, shows custom rules
2. Run semanage fcontext -a -f s -t httpd_var_run_t '/var/apps/\.sockets(/.*)?'
3. Run semanage fcontext -E
   → prints "KeyError: socket"

Cause

The root cause, from what I can see, is in seobject.py

Not sure if that fix is correct or if the lookup is wrong, but when I change the "s" value entry in file_type_str_to_option from "socket file" to "socket", it works as expected.

My first guess is that the lookup in that hash in line 2134 in my version (current version here) either needs to operate on a different hash, or that the input data is wrong, or that simply the hash is wrong and the above change is the correct fix.

This is really an issue for refpolicy and Android policy but putting it here so I remember to do it, since it is unlikely anyone else will.

There have been a number of changes to the kernel class/perm definitions (moving shared permissions to common definitions, removing obsolete classes/perms) since we switched to dynamic class/perm mappings that have not been mirrored to refpolicy or (to a lesser extent) Android policy due to concerns with backward compatibility. Since even RHEL6 has the dynamic class/perm mapping support back-ported, we ought to be able to do this even in refpolicy for many of the changes. Optimally, some day, we'd like to be able to completely synchronize them such that we have the identity mapping between the kernel and policy definitions, even though that's not necessary. Current caveats:

• Userspace can be brittle in the face of changes to their class definitions. Some old userspace used hardcoded definitions and will break if they change at all. Modern userspace supports at least dynamic class/perm mappings at initialization (e.g. selinux_set_mapping), but not all yet support dynamic class/perm mapping upon policy reload (e.g. selinux_check_access or equivalent). dbusd is the biggest known remaining offender, and needs its SELinux support overhauled in multiple ways. Xorg/XSELinux also has the same issue but it isn't used by default so it is less critical. Until we fix userspace, we can't make any changes that disturb the userspace class indices (which could happen e.g. just by removing or inserting a kernel class that precedes them, unless we replace it with a dummy placeholder class).

• Dropping of netlink_firewall and netilnk_ip6_fw didn't happen until Linux v3.5, so we can't drop unless we are willing to break compatibility for kernels < 3.5 (including RHEL6).

Android policy has already dropped unused permission definitions (only used in pre-mainline or compat_net < 2.6.30) and netlink_firewall and netlink_ip6_fw classes (< 3.5). Android policy doesn't include the Linux userspace object manager classes and all of its userspace object managers use selinux_check_access(), so they are already safe (plus Android does not officially support runtime policy reloads, although some devices do).

Work for this issue would include:

• Applying the same changes already done for Android policy to refpolicy, if acceptable from a refpolicy compatibility POV.
• Synchronizing common definitions between the kernel and both Android policy and refpolicy.
• Checking for any other inconsistencies that may have arisen between the kernel definitions and either refpolicy or Android policy.

Introduce warnings in the policy compiler toolchain for inconsistent combinations of policy capabilities and policy rules, e.g. using classes/permissions in rules without enabling the corresponding policy capability and vice versa.
Investigate lighter weight policy capability support, so that we can introduce new policy capabilities without needing to patch libsepol each time just to enable/use the new capability, e.g. allow passing capabilities to the kernel via uninterpreted string name rather than bitmap.

I've noticed a strange interaction with custom ports and booleans. After setting a boolean, the list of ports for a particular type (which has been customized) shows duplicate entries.

Example:

$ semanage port -a -t http_port_t -p tcp 12345
$ semanage port -l | grep http_port_t
http_port_t                    tcp      12345, 80, 81, 443, 488, 8008, 8009, 8443, 9000
$ setsebool -P zebra_write_config false
$ semanage port -l | grep http_port_t
http_port_t                    tcp      12345, 12345, 80, 81, 443, 488, 8008, 8009, 8443, 9000
$ setsebool -P zebra_write_config false
$ semanage port -l | grep http_port_t
http_port_t                    tcp      12345, 12345, 12345, 80, 81, 443, 488, 8008, 8009, 8443, 9000

As can be seen, each time a boolean is set persistently (it doesn't matter which boolean or which state), the custom port 12345 is duplicated. Running semodule -B clears the duplicates.

However, if only the local customizations are listed, the port is always listed only once:

$ semanage port -l -C
SELinux Port Type              Proto    Port Number

http_port_t                    tcp      12345

I'm using CentOS:

$ cat /etc/centos-release
CentOS Linux release 7.3.1611 (Core)
$ rpm -qf /usr/sbin/semanage 
policycoreutils-python-2.5-11.el7_3.x86_64

I'm going away for a few days, but I noticed the new behaviour with the digests feature affects fixfiles. The optimization can be turned off in restorecon/setfiles using the -I option. But fixfiles has no -I option, and never passes -I to restorecon/setfiles.

   This script is primarily used to correct the security context database (extended attributes) on filesystems.

  It  can  also  be  run  at  any time to relabel when adding support for new policy, or  just check whether the file contexts are all as you expect.

The "adding support for new policy" case, does not require -I. I'm not sure whether omitting -I actually helps anything or not in this case... I haven't read up on what use cases the digests are designed to help yet, I just ran into it as an optimization I needed to turn off.

But the other two cases, correcting contexts or checking contexts, do not seem to make much sense without passing -I to setfiles/restorecon.

I am getting this, on a RHEL 6.8 machine:

[fast@pandora]$ python
Python 2.6.6 (r266:84292, Aug  9 2016, 06:11:56)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-17)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import selinux
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python2.6/site-packages/selinux/__init__.py", line 25, in <module>
    _selinux = swig_import_helper()
  File "/usr/lib64/python2.6/site-packages/selinux/__init__.py", line 21, in swig_import_helper
    _mod = imp.load_module('_selinux', fp, pathname, description)
ImportError: /usr/lib64/python2.6/site-packages/selinux/_selinux.so: undefined symbol: selinux_set_policy_root
>>>

Can anyone shed some light? The following is the output of the installed selinux packages:

[fast@pandora]$ yum list installed | grep selinux
libselinux.x86_64          2.0.94-5.3.el6_4.1   installed
libselinux.x86_64          2.0.94-7.el6         @rhel-x86_64-server-6.8-20160802
libselinux-python.x86_64   2.0.94-7.el6         @rhel-x86_64-server-6.8-20160802
libselinux-ruby.x86_64     2.0.94-7.el6         @rhel-x86_64-server-6.8-20170131
libselinux-utils.x86_64    2.0.94-7.el6         @rhel-x86_64-server-6.8-20160802
selinux-policy.noarch      3.7.19-292.el6_8.2   @rhel-x86_64-server-6.8-20170131
selinux-policy-targeted.noarch

Long ago, Dan added a restorecon method to the libselinux swig python bindings (selinuxswig_python.i). Since there was no libselinux restorecon implementation at the time, he had it call matchpathcon(), which is deprecated in favor of selabel_lookup(), and implemented his own tree walk logic. Reimplement it using the selinux_restorecon() function now that it exists

Running the following command on Gentoo Linux profile=hardened/linux/amd64/selinux kernel= linux-4.4.39-gentoo, (kernel=linux-4.7.10-hardened)* with python version Python 3.4.5, produces syntax error in code found in:

File "/usr/lib/python-exec/python3.4/sepolicy", line 265

Syntax Discription: print "\n" + bold_start + "%s: %s %s" % (src, protocol, perm) + bold_end

Print commands in sepolicy.py: grep -Fr 'print ' /usr/lib/python-exec/python3.4/sepolicy

Command: sepolicy (with or without additional options syntax error is produced)

package name: sys-apps/policycoreutils

libsepol/checkpolicy do not presently handle ~self (including ~{ a b self }) correctly.
~ is only applied to the type set, not self, while self continues to be processed separately (without being complemented). We should either reject this as a syntax error in checkpolicy or handle it correctly in checkpolicy and libsepol.

avcstat.c:206]: (style) Redundant condition: !cumulative. 'cumulative || (!cumulative && !i)' is equivalent to 'cumulative || !i'

Source code is

   if (cumulative || (!cumulative && !i))

In the past, I have suggested not using security_compute_user() anymore and taking a simplified version of this logic entirely to userspace,
http://marc.info/?t=133054875600001&r=1&w=2

Obviously we could increase the kernel limit, but think about what the get_ordered_context_list() code is doing: it is asking the kernel to compute the complete set of reachable contexts (which is this case is huge because you are going from an unconfined domain to a user authorized for the unconfined role) and then throwing away the vast majority of the returned contexts because they don't match anything in /etc/selinux/targeted/contexts/default_contexts or /etc/selinux/targeted/contexts/users/ and then ultimately only using the first (highest priority) context from the ordered list. So the kernel computation is mostly wasted. Better to just cut it out entirely.

checkpolicy wrongly handles "-self". At the least, it should handle it as an error. At best, it should support it correctly (which would involve libsepol support as well). At present, it looks like it will end up negating (-) the next type/attribute in the list after self, or if there are no entries after self, ignoring it entirely.