Re: [PATCH v3] security/selinux: allow security_sb_clone_mnt_opts to enable/disable native labeling behavior
On Mon, Jun 5, 2017 at 8:46 PM, J . Bruce Fields wrote: > On Mon, Jun 05, 2017 at 05:21:55PM -0400, Paul Moore wrote: >> On Mon, Jun 5, 2017 at 11:45 AM, Scott Mayhew wrote: >> > When an NFSv4 client performs a mount operation, it first mounts the >> > NFSv4 root and then does path walk to the exported path and performs a >> > submount on that, cloning the security mount options from the root's >> > superblock to the submount's superblock in the process. >> > >> > Unless the NFS server has an explicit fsid=0 export with the >> > "security_label" option, the NFSv4 root superblock will not have >> > SBLABEL_MNT set, and neither will the submount superblock after cloning >> > the security mount options. As a result, setxattr's of security labels >> > over NFSv4.2 will fail. In a similar fashion, NFSv4.2 mounts mounted >> > with the context= mount option will not show the correct labels because >> > the nfs_server->caps flags of the cloned superblock will still have >> > NFS_CAP_SECURITY_LABEL set. >> > >> > Allowing the NFSv4 client to enable or disable SECURITY_LSM_NATIVE_LABELS >> > behavior will ensure that the SBLABEL_MNT flag has the correct value >> > when the client traverses from an exported path without the >> > "security_label" option to one with the "security_label" option and >> > vice versa. Similarly, checking to see if SECURITY_LSM_NATIVE_LABELS is >> > set upon return from security_sb_clone_mnt_opts() and clearing >> > NFS_CAP_SECURITY_LABEL if necessary will allow the correct labels to >> > be displayed for NFSv4.2 mounts mounted with the context= mount option. >> > >> > Signed-off-by: Scott Mayhew >> > --- >> > fs/nfs/super.c| 17 - >> > include/linux/lsm_hooks.h | 4 +++- >> > include/linux/security.h | 8 ++-- >> > security/security.c | 7 +-- >> > security/selinux/hooks.c | 35 +-- >> > 5 files changed, 63 insertions(+), 8 deletions(-) >> >> Thanks for sorting this out Scott and Stephen. >> >> NFS folks, any objections to this patch? If not, I'd like to pull >> this into the SELinux tree but I'd like to have an ACK from you before >> I do. > > Looks OK to me, but I think it's Trond or Anna (added to cc) that you > want the ACK from. It's been about four days with not comments from the NFS folks so I'm just going to go ahead and merge this into the selinux/next branch so we can get some more widespread testing. NFS folks, if you want to object please do so a week or two before the next merge window opens, otherwise I'm going to send this patch upstream. Thanks Scott for working on this patch, and everyone else for their comments, testing, and review. -- paul moore www.paul-moore.com
Re: [PATCH v2 2/2] selinux-testsuite: Infiniband endport tests
On 6/9/2017 3:01 PM, Paul Moore wrote: > On Fri, Jun 9, 2017 at 10:59 AM, Daniel Jurgens wrote: > > Should be all set now, let me know if you notice any problems. I did > add a separate third commit to munge the style/formatting (see > previous emails); I didn't bother posting it to the list as it is just > style changes, but in case anyone is curious, this is the commit: > > commit 8e0339cef20d0356d3e115c31a133662e9562e65 > Author: Paul Moore > Date: Fri Jun 9 15:46:37 2017 -0400 > >infiniband: apply style corrections to the infiniband tests > >Patch generated by './tools/check-syntax -f'. > >Signed-off-by: Paul Moore > >> I recall you saying you do most of your testing in VMs on a laptop. But if >> you have a system with a free pci-e slot we can ship you an HCA if you'd >> like to be able to run these yourself. > Thank you for the offer, and yes I generally run the tests in a VM, > however we've been working on getting something a bit more automated > in place for upstream testing (more info on that once everything is > sorted out). > > Let me think about this a bit (and dust off my somewhat neglected > testing hardware), I generally try to avoid getting tied to specific > hardware, but it is necessary in this case, and I fear that this may > be the easiest way to ensure it gets tested regularly. > OK, just let me know if you want one. Once the feature works it's way back to mainstream kernel I'll add the tests to our automated regressions too. Thanks for all your help getting this whole thing through review! How often does the fedora-selinux project switch the base refpolicy? It needs additions to the unconfined user role to allow access.
Re: [PATCH] security: selinux: use kmem_cache for ebitmap
On Thu, Jun 8, 2017 at 12:18 AM, Junil Lee wrote:
> The allocated size for each ebitmap_node is 192byte by kzalloc().
> Then, ebitmap_node size is fixed, so it's possible to use only 144byte
> for each object by kmem_cache_zalloc().
> It can reduce some dynamic allocation size.
>
> Signed-off-by: Junil Lee
> ---
> security/selinux/ss/ebitmap.c | 26 --
> security/selinux/ss/ebitmap.h | 3 +++
> security/selinux/ss/services.c | 4
> 3 files changed, 27 insertions(+), 6 deletions(-)
I just applied this to selinux/next, thank you.
> diff --git a/security/selinux/ss/ebitmap.c b/security/selinux/ss/ebitmap.c
> index 9db4709a..ad38299 100644
> --- a/security/selinux/ss/ebitmap.c
> +++ b/security/selinux/ss/ebitmap.c
> @@ -24,6 +24,8 @@
>
> #define BITS_PER_U64 (sizeof(u64) * 8)
>
> +static struct kmem_cache *ebitmap_node_cachep;
> +
> int ebitmap_cmp(struct ebitmap *e1, struct ebitmap *e2)
> {
> struct ebitmap_node *n1, *n2;
> @@ -54,7 +56,7 @@ int ebitmap_cpy(struct ebitmap *dst, struct ebitmap *src)
> n = src->node;
> prev = NULL;
> while (n) {
> - new = kzalloc(sizeof(*new), GFP_ATOMIC);
> + new = kmem_cache_zalloc(ebitmap_node_cachep, GFP_ATOMIC);
> if (!new) {
> ebitmap_destroy(dst);
> return -ENOMEM;
> @@ -162,7 +164,7 @@ int ebitmap_netlbl_import(struct ebitmap *ebmap,
> if (e_iter == NULL ||
> offset >= e_iter->startbit + EBITMAP_SIZE) {
> e_prev = e_iter;
> - e_iter = kzalloc(sizeof(*e_iter), GFP_ATOMIC);
> + e_iter = kmem_cache_zalloc(ebitmap_node_cachep,
> GFP_ATOMIC);
> if (e_iter == NULL)
> goto netlbl_import_failure;
> e_iter->startbit = offset - (offset % EBITMAP_SIZE);
> @@ -288,7 +290,7 @@ int ebitmap_set_bit(struct ebitmap *e, unsigned long bit,
> int value)
> prev->next = n->next;
> else
> e->node = n->next;
> - kfree(n);
> + kmem_cache_free(ebitmap_node_cachep, n);
> }
> return 0;
> }
> @@ -299,7 +301,7 @@ int ebitmap_set_bit(struct ebitmap *e, unsigned long bit,
> int value)
> if (!value)
> return 0;
>
> - new = kzalloc(sizeof(*new), GFP_ATOMIC);
> + new = kmem_cache_zalloc(ebitmap_node_cachep, GFP_ATOMIC);
> if (!new)
> return -ENOMEM;
>
> @@ -332,7 +334,7 @@ void ebitmap_destroy(struct ebitmap *e)
> while (n) {
> temp = n;
> n = n->next;
> - kfree(temp);
> + kmem_cache_free(ebitmap_node_cachep, temp);
> }
>
> e->highbit = 0;
> @@ -400,7 +402,7 @@ int ebitmap_read(struct ebitmap *e, void *fp)
>
> if (!n || startbit >= n->startbit + EBITMAP_SIZE) {
> struct ebitmap_node *tmp;
> - tmp = kzalloc(sizeof(*tmp), GFP_KERNEL);
> + tmp = kmem_cache_zalloc(ebitmap_node_cachep,
> GFP_KERNEL);
> if (!tmp) {
> printk(KERN_ERR
>"SELinux: ebitmap: out of memory\n");
> @@ -519,3 +521,15 @@ int ebitmap_write(struct ebitmap *e, void *fp)
> }
> return 0;
> }
> +
> +void ebitmap_cache_init(void)
> +{
> + ebitmap_node_cachep = kmem_cache_create("ebitmap_node",
> + sizeof(struct
> ebitmap_node),
> + 0, SLAB_PANIC, NULL);
> +}
> +
> +void ebitmap_cache_destroy(void)
> +{
> + kmem_cache_destroy(ebitmap_node_cachep);
> +}
> diff --git a/security/selinux/ss/ebitmap.h b/security/selinux/ss/ebitmap.h
> index 9637b8c..6d5a9ac 100644
> --- a/security/selinux/ss/ebitmap.h
> +++ b/security/selinux/ss/ebitmap.h
> @@ -130,6 +130,9 @@ void ebitmap_destroy(struct ebitmap *e);
> int ebitmap_read(struct ebitmap *e, void *fp);
> int ebitmap_write(struct ebitmap *e, void *fp);
>
> +void ebitmap_cache_init(void);
> +void ebitmap_cache_destroy(void);
> +
> #ifdef CONFIG_NETLABEL
> int ebitmap_netlbl_export(struct ebitmap *ebmap,
> struct netlbl_lsm_catmap **catmap);
> diff --git a/security/selinux/ss/services.c b/security/selinux/ss/services.c
> index 2021666..2f02fa6 100644
> --- a/security/selinux/ss/services.c
> +++ b/security/selinux/ss/services.c
> @@ -2054,9 +2054,11 @@ int security_load_policy(void *data, size_t len)
>
> if (!ss_initialized) {
> avtab_cache_init();
> + ebitmap_cache_init();
> rc = policydb_rea
Re: [PATCH v2 2/2] selinux-testsuite: Infiniband endport tests
On Fri, Jun 9, 2017 at 10:59 AM, Daniel Jurgens wrote: > On 6/9/2017 9:50 AM, Paul Moore wrote: >> On Fri, Jun 9, 2017 at 10:44 AM, Daniel Jurgens wrote: >>> On 6/5/2017 5:34 PM, Daniel Jurgens wrote: On 6/5/2017 5:13 PM, Paul Moore wrote: > On Tue, May 30, 2017 at 1:52 PM, Stephen Smalley > wrote: >> On Tue, 2017-05-30 at 17:40 +, Daniel Jurgens wrote: >>> On 5/30/2017 12:05 PM, Stephen Smalley wrote: On Tue, 2017-05-30 at 19:34 +0300, Dan Jurgens wrote: > From: Daniel Jurgens > > New tests for Infiniband endports. Most users do not have > infiniband > hardware, and if they do the device names can vary. There is a > configuration file for enabling the tests and setting environment > specific configurations. If the tests are disabled they always > show > as > passed. > > A special test application was unnecessary, a standard diagnostic > application is used instead. This required a change to the make > file > to avoid trying to build an application in the new subdir. > > Signed-off-by: Daniel Jurgens > ... > >> I wouldn't bother re-spinning unless Paul has other comments. > Nothing worthy of a respin. > > Daniel, have you run these tests against the kernel, userspace, and > policy code that has been merged? It would be nice to have a sanity > check that something didn't break while we were merging everything. > > [SIDE NOTE: This afternoon I noticed what I think may be a problem > with my COPR kernel builds that affects the test suite, so YMMY at the > moment.] > I ran them against the merged kernel and selinux code. But I used the same policy RPMs that I had been using, I didn't try to rebuild the RPMs against the new refpolicy. >>> Are these tests good to go? I haven't gotten any additional comments since >>> v2. >> Yes, my apologies for not getting back to you sooner; I had hoped to >> talk to some of the IB folks at Red Hat to see if they could verify >> everything (or at least get access to a IB system so I could verify >> it) but I got wrapped in a few audit issues this week and didn't get >> to it. >> >> I'll merge these patches later this afternoon. >> > No problem, just wanted to make sure I wasn't holding it up in anyway. Should be all set now, let me know if you notice any problems. I did add a separate third commit to munge the style/formatting (see previous emails); I didn't bother posting it to the list as it is just style changes, but in case anyone is curious, this is the commit: commit 8e0339cef20d0356d3e115c31a133662e9562e65 Author: Paul Moore Date: Fri Jun 9 15:46:37 2017 -0400 infiniband: apply style corrections to the infiniband tests Patch generated by './tools/check-syntax -f'. Signed-off-by: Paul Moore > I recall you saying you do most of your testing in VMs on a laptop. But if > you have a system with a free pci-e slot we can ship you an HCA if you'd like > to be able to run these yourself. Thank you for the offer, and yes I generally run the tests in a VM, however we've been working on getting something a bit more automated in place for upstream testing (more info on that once everything is sorted out). Let me think about this a bit (and dust off my somewhat neglected testing hardware), I generally try to avoid getting tied to specific hardware, but it is necessary in this case, and I fear that this may be the easiest way to ensure it gets tested regularly. -- paul moore www.paul-moore.com
Re: ANN: SELinux userspace 2.7-rc1 release
On Fri, 2017-06-09 at 13:18 -0400, Stephen Smalley wrote: > A release candidate for the SELinux userspace is now available at: > https://github.com/SELinuxProject/selinux/wiki/Releases git shortlog output for this release. Alan Jenkins (24): policycoreutils, python: Fix bad manpage formatting in "SEE ALSO" restorecon manpage: link back to fixfiles policycoreutils: let output of `fixfiles` be redirected (as normal) policycoreutils: fixfiles should handle path arguments more robustly policycoreutils: fixfiles: handle unexpected spaces in command policycoreutils/setfiles: stdout messages don't need program prefix policycoreutils/setfiles: don't scramble stdout and stderr together policycoreutils: fixfiles: remove useless use of cat Revert "policycoreutils: let output of `fixfiles` be redirected (as normal)" policycoreutils: fixfiles: remove (broken) redundant code policycoreutils: fixfiles: clarify exclude_dirs() policycoreutils: fixfiles: fix logging about R/O filesystems policycoreutils: fixfiles: move logit call outside of redirected function policycoreutils: fixfiles: deprecate -l option policycoreutils: fixfiles: tidy up usage(), manpage synopsis policycoreutils: fixfiles: remove two unused variables policycoreutils: fixfiles: syntax error policycoreutils: fixfiles: usage errors are fatal policycoreutils: fixfiles: if restorecon aborts, we should too policycoreutils: fixfiles: refactor into the `set -u` dialect policycoreutils: fixfiles: un-document `-R -a` option policycoreutils: fixfiles: remove bad modes of "relabel" command policycoreutils: fixfiles: don't ignore `-F` when run in `-C` mode policycoreutils: fixfiles: use a consistent order for options to restorecon Bernhard M. Wiedemann (1): sort input files Christian Göttsche (2): libselinux: add security_get_checkreqprot sestatus: show checkreqprot status Colin Walters (1): config: Don't finalize mount state in selinux_set_policy_root() Dan Walsh (5): policycoreutils/sepolicy: Add documentation for MCS separated domains sepolicy: Add manpages for typealiased types sepolicy: Move svirt man page out of libvirt into its own Fix up generation of application policy sepolicy: We should be creating _exec interfaces when we create the domtrans interface Daniel Jurgens (10): checkpolicy: Add support for ibpkeycon labels libsepol: Add ibpkey ocontext handling libsepol: Add Infiniband Pkey handling to CIL checkpolicy: Add support for ibendportcon labels libsepol: Add ibendport ocontext handling libsepol: Add IB end port handling to CIL semanage: Update semanage to allow runtime labeling of Infiniband Pkeys semanage: Update semanage to allow runtime labeling of ibendports semanage: Update man pages for infiniband semanage: Fix manpage author for ibpkey and ibendport pages. Gary Tierney (1): libsepol/cil: remove avrules with no affected types Guido Trentalancia (2): libselinux: Fix unitialized variable compiler warnings libsemanage: Fix unitialized variable compiler warnings James Carter (42): libsepol/cil: Check for improper category range libsepol/cil: Use empty list for category expression evaluated as empty libsepol/cil: Use an empty list to represent an unknown permission libsepol/cil: Check if identifier is NULL when verifying name libsepol/cil: Check that permission is not an empty list libsepol/cil: Verify alias in aliasactual statement is really an alias libsepol/cil: Verify neither child nor parent in a bounds is an attribute Updated libsepol ChangeLog. Updated libsepol ChangeLog. libsepol/cil: Exit with an error for an unknown map permission Updated libsepol ChangeLog. libsepol/cil: Add ability to write policy.conf file from CIL AST secilc: Add secil2conf which creates a policy.conf from CIL policy libsepol: Fix neverallow checking to also check the other types when self is included in a target type set. checkpolicy: Create common function for type declares and requires checkpolicy: Create common function for role declares and requires checkpolicy: Create common function for user declares and requires checkpolicy: Cleanup error messages checkpolicy: Move common require and declare code into new function checkpolicy: Improve check for identifier flavor mismatch libsepol: Return +1 when declaration is followed by a require checkpolicy: Remove uneeded return check in require_symbol() checkpolicy: Make print_error_msg() static policycoreutils/semodule: fix -Wwrite-strings warnings libsepol/cil: Destroy cil_tree_node stacks when finished resolving AST libsepol/cil: Move initialization of bitmap in __cil_permx_to_bitmap
ANN: SELinux userspace 2.7-rc1 release
A release candidate for the SELinux userspace is now available at: https://github.com/SELinuxProject/selinux/wiki/Releases Please give it a test and let us know if there are any issues. Below are some notes on this release for packagers and users of the SELinux userspace. A git shortlog will follow in a separate email. If you see (or encounter) other changes that you think are important to call out for packagers and users in the final release announcement, let us know. Also, since we have removed the older manually maintained ChangeLog files, let us know whether you would like to see a full ChangeLog (generated via git log) and/or shortlog for the entire release or by individual component added to the release (and if so, whether this ought to go into the tar files themselves or can be separate on the download page). 1) This will be the first release with the split up policycoreutils (see https://www.mail-archive.com/selinux@tycho.nsa.gov/msg02914.html and the rest of that thread). If there are any final desired changes to the structure, naming, etc, now is the last opportunity to get it fixed before we make a final release with the new structure/naming. Fedora already packages many of these components separately, although not always with the same organization and naming scheme. Note that a number of these components are not necessary for basic use of SELinux and likely should not be installed by default, e.g. selinux-dbus, selinux-gui, mcstrans, restorecond, selinux-sandbox. 2) libsepol now has binary module support for ioctl xperms rules (module version 18), making it possible to use allowxperm rules in modularly built refpolicy-based policies. Previously, ioctl xperms rules were only supported in monolithic policy and in CIL modules. This change means that refpolicy and/or policies derived from it can begin to leverage ioctl whitelisting, which has already been leveraged for some time in Android policies, which do not rely on binary modules. 3) This release introduces support for Infiniband object labeling, including support for kernel policy version 31 and module version 19, policy.conf and CIL language support, and semanage support. It appears that the corresponding kernel support will land in Linux v4.13. 4) This release introduces support for building policies with the extended_socket_class and cgroup_seclabel policy capabilities enabled. The extended_socket_class policy capability allows distinctions to be made in policy among socket address families that were previously mapped to the generic socket class (e.g. bluetooth, nfc, and many other socket address families that previously did not have their own distinct security class) as well as for SCTP and ICMP/ping sockets that were previously mapped to the rawip_socket class. This policy capability is supported by Linux v4.11 and later. refpolicy master already includes the class/permission definitions for this capability but does not yet enable the capability by default (and further allow rules will be necessary to allow access to the new socket classes; review all allow rules on socket and rawip_socket and see whether they should be duplicated for the new classes but do not blindly allow access to them all). AOSP master policy also includes the class/permission definitions for this policy capability and enables the capability by default, and will likewise need corresponding allow rules added when kernels >= 4.11 are used. The cgroup_seclabel policy capability allows userspace to set labels on cgroup/cgroup2 files, enabling fine-grained labeling of cgroup files by userspace. This policy capability is also supported by Linux v4.11 and later. This capability is not yet defined in any policy. Note that enabling this capability will break current Android userspace/policy and requires introducing appropriate file_contexts definitions for cgroup files (or a change to the Android init program's handling of them) in order to avoid mislabeling them. 5) checkpolicy now supports for generating CIL or policy.conf from a kernel binary policy. Sample usage is checkpolicy -M -C -b policy.N -o policy.cil and checkpolicy -M -F -b policy.N -o policy.conf. There is also now a secil2conf program that can generate policy.conf from CIL, e.g. secil2conf -o policy.conf policy.cil. 6) Attribute generation and expansion has changed in several ways in order to address kernel runtime performance issues that occur when types have many attributes assigned to them while ensuring preservation of attributes where desired. Binary module to CIL conversion now ensures that duplicate attributes are not generated for the same type set. secilc now supports -G and -X options to force expansion of automatically generated attributes (-G) and/or attributes that have fewer than a specified number of types (-X number). secilc will also now more aggressively expand attributes based on whether they will actually be used by the kernel, are needed for debugging denials by a
[PATCH] libsepol: Fix neverallow bug when checking conditional policy
Commit 9e6840e refactored neverallow checking. In the process a bug was introduced that causes enabled conditional rules to be skipped. The bug is that the avtab key is checked by comparing the specified field of the key to the value AVTAB_ALLOWED. Since enabled conditional rules have an additional bit set as well, these rules are not considered to match. The fix is to use a bitwise AND (&) to only check the desired bit. Signed-off-by: James Carter --- libsepol/src/assertion.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libsepol/src/assertion.c b/libsepol/src/assertion.c index 27c39e7..ba8f927 100644 --- a/libsepol/src/assertion.c +++ b/libsepol/src/assertion.c @@ -222,7 +222,7 @@ static int report_assertion_avtab_matches(avtab_key_t *k, avtab_datum_t *d, void ebitmap_node_t *snode, *tnode; unsigned int i, j; - if (k->specified != AVTAB_ALLOWED) + if (k->specified & AVTAB_ALLOWED == 0) return 0; if (!match_any_class_permissions(avrule->perms, k->target_class, d->data)) @@ -471,7 +471,7 @@ static int check_assertion_avtab_match(avtab_key_t *k, avtab_datum_t *d, void *a avrule_t *avrule = a->avrule; avtab_t *avtab = a->avtab; - if (k->specified != AVTAB_ALLOWED) + if (k->specified & AVTAB_ALLOWED == 0) goto exit; if (!match_any_class_permissions(avrule->perms, k->target_class, d->data)) -- 2.9.4
Re: [PATCH v2 2/2] selinux-testsuite: Infiniband endport tests
On 6/9/2017 9:50 AM, Paul Moore wrote: > On Fri, Jun 9, 2017 at 10:44 AM, Daniel Jurgens wrote: >> On 6/5/2017 5:34 PM, Daniel Jurgens wrote: >>> On 6/5/2017 5:13 PM, Paul Moore wrote: On Tue, May 30, 2017 at 1:52 PM, Stephen Smalley wrote: > On Tue, 2017-05-30 at 17:40 +, Daniel Jurgens wrote: >> On 5/30/2017 12:05 PM, Stephen Smalley wrote: >>> On Tue, 2017-05-30 at 19:34 +0300, Dan Jurgens wrote: From: Daniel Jurgens New tests for Infiniband endports. Most users do not have infiniband hardware, and if they do the device names can vary. There is a configuration file for enabling the tests and setting environment specific configurations. If the tests are disabled they always show as passed. A special test application was unnecessary, a standard diagnostic application is used instead. This required a change to the make file to avoid trying to build an application in the new subdir. Signed-off-by: Daniel Jurgens ... > I wouldn't bother re-spinning unless Paul has other comments. Nothing worthy of a respin. Daniel, have you run these tests against the kernel, userspace, and policy code that has been merged? It would be nice to have a sanity check that something didn't break while we were merging everything. [SIDE NOTE: This afternoon I noticed what I think may be a problem with my COPR kernel builds that affects the test suite, so YMMY at the moment.] >>> I ran them against the merged kernel and selinux code. But I used the same >>> policy RPMs that I had been using, I didn't try to rebuild the RPMs against >>> the new refpolicy. >>> >> Are these tests good to go? I haven't gotten any additional comments since >> v2. > Yes, my apologies for not getting back to you sooner; I had hoped to > talk to some of the IB folks at Red Hat to see if they could verify > everything (or at least get access to a IB system so I could verify > it) but I got wrapped in a few audit issues this week and didn't get > to it. > > I'll merge these patches later this afternoon. > No problem, just wanted to make sure I wasn't holding it up in anyway. I recall you saying you do most of your testing in VMs on a laptop. But if you have a system with a free pci-e slot we can ship you an HCA if you'd like to be able to run these yourself.
Re: [PATCH v2 2/2] selinux-testsuite: Infiniband endport tests
On Fri, Jun 9, 2017 at 10:44 AM, Daniel Jurgens wrote: > On 6/5/2017 5:34 PM, Daniel Jurgens wrote: >> On 6/5/2017 5:13 PM, Paul Moore wrote: >>> On Tue, May 30, 2017 at 1:52 PM, Stephen Smalley wrote: On Tue, 2017-05-30 at 17:40 +, Daniel Jurgens wrote: > On 5/30/2017 12:05 PM, Stephen Smalley wrote: >> On Tue, 2017-05-30 at 19:34 +0300, Dan Jurgens wrote: >>> From: Daniel Jurgens >>> >>> New tests for Infiniband endports. Most users do not have >>> infiniband >>> hardware, and if they do the device names can vary. There is a >>> configuration file for enabling the tests and setting environment >>> specific configurations. If the tests are disabled they always >>> show >>> as >>> passed. >>> >>> A special test application was unnecessary, a standard diagnostic >>> application is used instead. This required a change to the make >>> file >>> to avoid trying to build an application in the new subdir. >>> >>> Signed-off-by: Daniel Jurgens >>> ... >>> I wouldn't bother re-spinning unless Paul has other comments. >>> Nothing worthy of a respin. >>> >>> Daniel, have you run these tests against the kernel, userspace, and >>> policy code that has been merged? It would be nice to have a sanity >>> check that something didn't break while we were merging everything. >>> >>> [SIDE NOTE: This afternoon I noticed what I think may be a problem >>> with my COPR kernel builds that affects the test suite, so YMMY at the >>> moment.] >>> >> I ran them against the merged kernel and selinux code. But I used the same >> policy RPMs that I had been using, I didn't try to rebuild the RPMs against >> the new refpolicy. >> > Are these tests good to go? I haven't gotten any additional comments since v2. Yes, my apologies for not getting back to you sooner; I had hoped to talk to some of the IB folks at Red Hat to see if they could verify everything (or at least get access to a IB system so I could verify it) but I got wrapped in a few audit issues this week and didn't get to it. I'll merge these patches later this afternoon. -- paul moore www.paul-moore.com
Re: [PATCH v2 2/2] selinux-testsuite: Infiniband endport tests
On 6/5/2017 5:34 PM, Daniel Jurgens wrote: > On 6/5/2017 5:13 PM, Paul Moore wrote: >> On Tue, May 30, 2017 at 1:52 PM, Stephen Smalley wrote: >>> On Tue, 2017-05-30 at 17:40 +, Daniel Jurgens wrote: On 5/30/2017 12:05 PM, Stephen Smalley wrote: > On Tue, 2017-05-30 at 19:34 +0300, Dan Jurgens wrote: >> From: Daniel Jurgens >> >> New tests for Infiniband endports. Most users do not have >> infiniband >> hardware, and if they do the device names can vary. There is a >> configuration file for enabling the tests and setting environment >> specific configurations. If the tests are disabled they always >> show >> as >> passed. >> >> A special test application was unnecessary, a standard diagnostic >> application is used instead. This required a change to the make >> file >> to avoid trying to build an application in the new subdir. >> >> Signed-off-by: Daniel Jurgens >> ... >> >>> I wouldn't bother re-spinning unless Paul has other comments. >> Nothing worthy of a respin. >> >> Daniel, have you run these tests against the kernel, userspace, and >> policy code that has been merged? It would be nice to have a sanity >> check that something didn't break while we were merging everything. >> >> [SIDE NOTE: This afternoon I noticed what I think may be a problem >> with my COPR kernel builds that affects the test suite, so YMMY at the >> moment.] >> > I ran them against the merged kernel and selinux code. But I used the same > policy RPMs that I had been using, I didn't try to rebuild the RPMs against > the new refpolicy. > Are these tests good to go? I haven't gotten any additional comments since v2.
[PATCH] libselinux: always unmount selinuxfs for SELINUX=disabled
As reported in:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864479
using a kernel configuration with CONFIG_SECURITY_SELINUX_DISABLE=n
and a /etc/selinux/config with SELINUX=disabled leads to a boot
failure.
Fix this by always unmounting selinuxfs if /etc/selinux/config has
SELINUX=disabled even if unable to successfully disable SELinux.
This will ensure that subsequent is_selinux_enabled() tests will
return 0 (disabled) and userspace will therefore skip any SELinux
processing.
Reported-by: Christian Göttsche
Reported-by: Laurent Bigonville
Signed-off-by: Stephen Smalley
---
libselinux/src/load_policy.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libselinux/src/load_policy.c b/libselinux/src/load_policy.c
index 7f08311..e9f1264 100644
--- a/libselinux/src/load_policy.c
+++ b/libselinux/src/load_policy.c
@@ -449,8 +449,11 @@ int selinux_init_load_policy(int *enforce)
}
}
- if (seconfig == -1)
+ if (seconfig == -1) {
+ umount(selinux_mnt);
+ fini_selinuxmnt();
goto noload;
+ }
/* Load the policy. */
return selinux_mkload_policy(0);
--
2.9.4
Re: boot failure due to ambiguous SELinux config
On Fri, 2017-06-09 at 14:52 +0200, Christian Göttsche wrote: > 2017-06-09 14:45 GMT+02:00 Stephen Smalley : > > Kernel version and config, particularly the CONFIG_SECURITY_SELINUX > > ones? And are you using any other SELinux-related kernel command > > line > > options (e.g. enforcing=, selinux=)? > > standard Debian sid kernel: Linux server02 4.9.0-3-amd64 #1 SMP > Debian > 4.9.30-1 (2017-06-04) x86_64 GNU/Linux > > $ grep -i selinux /boot/config-4.9.0-3-amd64 > CONFIG_SECURITY_SELINUX=y > # CONFIG_SECURITY_SELINUX_BOOTPARAM is not set > # CONFIG_SECURITY_SELINUX_DISABLE is not set > CONFIG_SECURITY_SELINUX_DEVELOP=y > CONFIG_SECURITY_SELINUX_AVC_STATS=y > CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=0 > # CONFIG_DEFAULT_SECURITY_SELINUX is not set > > $ cat /proc/cmdline > BOOT_IMAGE=/boot/vmlinuz-4.9.0-3-amd64 > root=UUID=1e528afb-83e1-489e-b2f7-1ad1d73d145c ro security=selinux > nomodeset elevator=noop Thanks, that makes it clear. On the one hand, this is a case of misconfiguration, and on the other, it is a bug/regression in libselinux. Your kernel configuration says "Enable SELinux, and don't allow disabling it at boot via selinux=0 nor from userspace via /sys/fs/selinux/disable (the latter is what is used for /etc/selinux/config SELINUX=disabled)." Your userspace configuration says "Disable SELinux from userspace via /sys/fs/selinux/disable". You really shouldn't use that set of configurations together. That said, libselinux could handle this situation more gracefully (and in fact, used to do so, so this is also a regression). libselinux selinux_init_load_policy() tries to honor your /etc/selinux/config SELINUX=disabled setting and tries to write to /sys/fs/selinux/disable via security_disable(). This fails since you disabled that in your kernel configuration. So selinux_init_load_policy() tries to fall back to just not loading policy (and setting SELinux to permissive if not already, in case a policy has already been loaded earlier, e.g. in the case of a systemd switch-root from a SELinux enabled to a SELinux disabled environment). This used to be sufficient, since is_selinux_enabled() used to also test whether a policy has been loaded and treat that as disabled. However, we reduced is_selinux_enabled() to only testing for a selinuxfs mount in commit 685f4aeeadc0b60f3770404d4f149610d656e3c8 since the no-policy-loaded test was a relic of the time before there was runtime disable support and the no-policy-loaded test was creating deadlock when using nvidia libGL, https://bugzilla.redhat.com/show_bug.cgi?id=1195074 So selinux_init_load_policy() really ought to unmount selinuxfs after setting SELinux permissive in this case so that is_selinux_enabled() will still return disabled. Then dbus and the rest of userspace will handle things properly.
Re: boot failure due to ambiguous SELinux config
2017-06-09 14:45 GMT+02:00 Stephen Smalley : > Kernel version and config, particularly the CONFIG_SECURITY_SELINUX > ones? And are you using any other SELinux-related kernel command line > options (e.g. enforcing=, selinux=)? standard Debian sid kernel: Linux server02 4.9.0-3-amd64 #1 SMP Debian 4.9.30-1 (2017-06-04) x86_64 GNU/Linux $ grep -i selinux /boot/config-4.9.0-3-amd64 CONFIG_SECURITY_SELINUX=y # CONFIG_SECURITY_SELINUX_BOOTPARAM is not set # CONFIG_SECURITY_SELINUX_DISABLE is not set CONFIG_SECURITY_SELINUX_DEVELOP=y CONFIG_SECURITY_SELINUX_AVC_STATS=y CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=0 # CONFIG_DEFAULT_SECURITY_SELINUX is not set $ cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-4.9.0-3-amd64 root=UUID=1e528afb-83e1-489e-b2f7-1ad1d73d145c ro security=selinux nomodeset elevator=noop
Re: boot failure due to ambiguous SELinux config
On Fri, 2017-06-09 at 13:25 +0200, Laurent Bigonville wrote: > Hello, > > I just got the following bugreport in debian that I've been able to > reproduce myself: > > When booting with a kernel cmdline 'security=selinux' and a > /etc/selinux/config setting 'SELINUX=disabled', dbus fails to start > and thereby systemd-logind and the system is unusable: > > Jun 08 16:23:43 server02 systemd[1]: Started D-Bus System Message > Bus. > Jun 08 16:23:43 server02 dbus-daemon[703]: Failed to set up security > class mapping (selinux_set_mapping():Invalid argument). > Jun 08 16:24:08 server02 systemd[1]: dbus.service: Main process > exited, code=exited, status=1/FAILURE > Jun 08 16:24:08 server02 systemd[1]: dbus.service: Unit entered > failed state. > Jun 08 16:24:08 server02 systemd[1]: dbus.service: Failed with result > 'exit-code'. > > When accessing the system using a debug shell, I can see that the > selinuxfs is mounted and sestatus is telling me that selinux is > enabled. > I can manually unmount the selinuxfs and then sestatus is telling me > that selinux is disabled on the system. > > Looking quickly at the code, the selinux_init_load_policy() function > (which is used in systemd) is supposed to unmount the selinuxfs > itself > if the SELINUX parameter is set to disabled in /etc/selinux/config > file. > I'm not too sure why it's not happening or maybe something else is > remounting it? I don't think anything else on the system is trying > to > load the policy though. > > An idea? > > Laurent Bigonville > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864479 Kernel version and config, particularly the CONFIG_SECURITY_SELINUX ones? And are you using any other SELinux-related kernel command line options (e.g. enforcing=, selinux=)?
Re: tomcat_t domain behavior
Hi,
It seems the bug is fixed on selinux-policy-3.13.1-145.el7.noarch.rpm. :-)
So I uploaded new article on our blog.
"CVE-2017-5638(Struts2) PoC with SELinux"
Now we can say SELinux can mitigate the Struts2(CVE-2017-5638)
if the policy is latest(3.13.1-145).
http://www.secureoss.jp/post/omok-selinux-struts2-20170607/
Kind Regards,
OMO
2017-03-14 22:42 GMT+09:00 面和毅 :
> Dear Lukas,
>
> Thanks. I also submitted this issue on bugzilla for RHEL7.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1432083
>
> Kind Regards,
>
> OMO
>
> 2017-03-14 21:35 GMT+09:00 面和毅 :
>> Dear Gary, Lukas,
>>
>> Many Thanks.
>>
>> I just submitted this issue on bugzilla for Fedora.
>> https://bugzilla.redhat.com/show_bug.cgi?id=1432055
>>
>> After I install RHEL7.3(because I tested it on CentOS7), I'll submit
>> it on RHEL also.
>>
>> Kind Regards,
>>
>> OMO
>>
>> 2017-03-14 20:20 GMT+09:00 Lukas Vrabec :
>>> On 03/14/2017 11:39 AM, Gary Tierney wrote:
On Tue, Mar 14, 2017 at 12:24:32PM +0900, 面和毅 wrote:
>
> Hi list,
>
> I just found strange behavior on tomcat_t.
> (I checked Fedora25, CentOS7).
>
> During PoC for CVE-2017-5638(I know RedHat products are
> not affected, just wanted to confirm SELinux behavior),
> I found that tomcat_t can read shadow_t file, access to
> admin_home_t directory, and so on.
>
> I guess there is a suitable reason to allow those permission
> to tomcat_t, but I just want to confirm the reason.
>
> - Quick test for tomcat_t -;
> I did just temporary test for checking tomcat_t behavior
> on Fedora25.
>
> 1. I copied /bin/bash to /root/tomcat_shell.sh, and assigned
>context as "tomcat_exec_t".
>
> [root@fedora25 ~]# ls -lZ /root/tomcat_shell.sh
> -rwxr-xr-x. 1 root root system_u:object_r:tomcat_exec_t:s0
> 1072008 Mar 14 11:53 /root/tomcat_shell.sh
>
> 2. I added some cil policy just for this test.
> [root@fedora25 ~]# cat tomcat_sh.cil
> (typeattributeset entry_type tomcat_exec_t)
> (roletype unconfined_r tomcat_t)
> (typetransition unconfined_t tomcat_exec_t process tomcat_t)
>
> 3. load above module, and run tomcat_shell.sh
> [root@fedora25 ~]# semodule -i tomcat_sh.cil
> [root@fedora25 ~]# ./tomcat_shell.sh
> [root@fedora25 ~]# id -Z
> unconfined_u:unconfined_r:tomcat_t:s0-s0:c0.c1023
>
> 4. access to shadow file, /root/ file, etc.
> [root@fedora25 ~]# cat /etc/shadow
> root:$6$h0wd.::0:9:7:::
> bin:*:17004:0:9:7:::
> daemon:*:17004:0:9:7:::
> --snip--
> [root@fedora25 ~]# cat /root/tomcat_sh.cil
> (typeattributeset entry_type tomcat_exec_t)
> (roletype unconfined_r tomcat_t)
> (typetransition unconfined_t tomcat_exec_t process tomcat_t)
> [root@fedora25 ~]# ls -lZ /root/tomcat_sh.cil
> -rw-r--r--. 1 root root unconfined_u:object_r:admin_home_t:s0
> 138 Mar 14 12:01 /root/tomcat_sh.cil
> - End -
>
> So, can I ask the reason why we add these permission to tomcat_t?
>>>
>>> There is no reason to have tomcat_t domain in uconfined_domain.
>>>
>>>
These permissions aren't directly added to tomcat, they come from tomcat
being an unconfined domain:
https://github.com/fedora-selinux/selinux-policy-contrib/blob/f25/tomcat.te#L21
$ sesearch -ACS -s tomcat_t -t shadow_t -c file -p read
Found 1 semantic av rules:
allow files_unconfined_type file_type : file { ioctl read write create
getattr setattr lock relabelfrom relabelto append unlink link rename
execute
swapon quotaon mounton execute_no_trans open audit_access } ;
$ seinfo -ttomcat_t -x
tomcat_t
can_read_shadow_passwords
can_write_shadow_passwords
can_relabelto_shadow_passwords
can_change_object_identity
can_load_kernmodule
can_load_policy
can_setbool
can_setenforce
corenet_unconfined_type
corenet_unlabeled_type
devices_unconfined_type
domain
files_unconfined_type
filesystem_unconfined_type
kern_unconfined
kernel_system_state_reader
process_uncond_exempt
selinux_unconfined_type
storage_unconfined_type
unconfined_domain_type
dbusd_unconfined
daemon
syslog_client_type
sepgsql_unconfined_type
tomcat_domain
userdom_filetrans_type
x_domain
xserver_unconfined_type
I don't see why Tomcat would need to be an unconfined domain, though.
>>>
>>> tomcat_t is in unconfined_domain_type attribute in Fedora 25 and Centos7.
>>> This looks like bug when tomcat policy was written.
>>>
>>> Could you please submit bug for Fedora and also RHEL? It should be fixed.
>>>
>>> Lukas.
>>>
>
> Kind Regards,
>
> OMO
boot failure due to ambiguous SELinux config
Hello, I just got the following bugreport in debian that I've been able to reproduce myself: When booting with a kernel cmdline 'security=selinux' and a /etc/selinux/config setting 'SELINUX=disabled', dbus fails to start and thereby systemd-logind and the system is unusable: Jun 08 16:23:43 server02 systemd[1]: Started D-Bus System Message Bus. Jun 08 16:23:43 server02 dbus-daemon[703]: Failed to set up security class mapping (selinux_set_mapping():Invalid argument). Jun 08 16:24:08 server02 systemd[1]: dbus.service: Main process exited, code=exited, status=1/FAILURE Jun 08 16:24:08 server02 systemd[1]: dbus.service: Unit entered failed state. Jun 08 16:24:08 server02 systemd[1]: dbus.service: Failed with result 'exit-code'. When accessing the system using a debug shell, I can see that the selinuxfs is mounted and sestatus is telling me that selinux is enabled. I can manually unmount the selinuxfs and then sestatus is telling me that selinux is disabled on the system. Looking quickly at the code, the selinux_init_load_policy() function (which is used in systemd) is supposed to unmount the selinuxfs itself if the SELINUX parameter is set to disabled in /etc/selinux/config file. I'm not too sure why it's not happening or maybe something else is remounting it? I don't think anything else on the system is trying to load the policy though. An idea? Laurent Bigonville https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864479
