Re: [PATCH V33 24/30] bpf: Restrict bpf when kernel lockdown is in confidentiality mode

On 6/26/19 8:57 PM, Andy Lutomirski wrote: On Jun 26, 2019, at 1:22 PM, James Morris wrote: [Adding the LSM mailing list: missed this patchset initially] On Thu, 20 Jun 2019, Andy Lutomirski wrote: This patch exemplifies why I don't like this approach: @@ -97,6 +97,7 @@ enum

Re: What do LSMs *actually* need for checks on notifications?

On 6/12/19 7:43 AM, David Howells wrote: Stephen Smalley wrote: (6) The security attributes of all the objects between the object in (5) and the object in (4), assuming we work from (5) towards (4) if the two aren't coincident (WATCH_INFO_RECURSIVE). Does this apply

Re: [RFC PATCH v1 2/3] LSM/x86/sgx: Implement SGX specific hooks in SELinux

On 6/11/19 6:55 PM, Xing, Cedric wrote: From: linux-sgx-ow...@vger.kernel.org [mailto:linux-sgx- ow...@vger.kernel.org] On Behalf Of Stephen Smalley Sent: Tuesday, June 11, 2019 6:40 AM +#ifdef CONFIG_INTEL_SGX + rc = sgxsec_mprotect(vma, prot); + if (rc <

Re: [RFC PATCH v1 2/3] LSM/x86/sgx: Implement SGX specific hooks in SELinux

On 6/11/19 6:02 PM, Sean Christopherson wrote: On Tue, Jun 11, 2019 at 09:40:25AM -0400, Stephen Smalley wrote: I haven't looked at this code closely, but it feels like a lot of SGX-specific logic embedded into SELinux that will have to be repeated or reused for every security module. Does SGX

Re: [RFC PATCH v2 3/5] x86/sgx: Enforce noexec filesystem restriction for enclaves

On 6/10/19 12:44 PM, Andy Lutomirski wrote: On Mon, Jun 10, 2019 at 9:00 AM Jarkko Sakkinen wrote: On Wed, Jun 05, 2019 at 07:11:43PM -0700, Sean Christopherson wrote: + goto out; + } + + /* + * Query VM_MAYEXEC as an indirect path_noexec() check (see do_mmap()), +

Re: What do LSMs *actually* need for checks on notifications?

On 6/11/19 10:21 AM, David Howells wrote: To see if we can try and make progress on this, can we try and come at this from another angle: what do LSMs *actually* need to do this? And I grant that each LSM might require different things. I think part of the problem here is that the discussion

Re: [RFC PATCH v1 2/3] LSM/x86/sgx: Implement SGX specific hooks in SELinux

On 6/10/19 3:03 AM, Cedric Xing wrote: In this patch, SELinux maintains two bits per enclave page, namely SGX__EXECUTE and SGX__EXECMOD. SGX__EXECUTE is set initially (by selinux_enclave_load) for every enclave page that was loaded from a potentially executable source page. SGX__EXECMOD is set

Re: [RFC PATCH v2 5/5] security/selinux: Add enclave_load() implementation

On 6/5/19 10:11 PM, Sean Christopherson wrote: The goal of selinux_enclave_load() is to provide a facsimile of the existing selinux_file_mprotect() and file_map_prot_check() policies, but tailored to the unique properties of SGX. For example, an enclave page is technically backed by a

Re: [RFC PATCH v2 4/5] LSM: x86/sgx: Introduce ->enclave_load() hook for Intel SGX

On 6/5/19 10:11 PM, Sean Christopherson wrote: enclave_load() is roughly analogous to the existing file_mprotect(). Due to the nature of SGX and its Enclave Page Cache (EPC), all enclave VMAs are backed by a single file, i.e. /dev/sgx/enclave, that must be MAP_SHARED. Furthermore, all enclaves

Re: [RFC][PATCH 00/10] Mount, FS, Block and Keyrings notifications [ver #3]

On 6/6/19 9:16 AM, David Howells wrote: Stephen Smalley wrote: This might be easier to discuss if you can reply to: https://lore.kernel.org/lkml/5393.1559768...@warthog.procyon.org.uk/ which is on the ver #2 posting of this patchset. Sorry for being late to the party. Not sure

Re: [RFC PATCH 0/9] security: x86/sgx: SGX vs. LSM

On 6/3/19 2:30 PM, Xing, Cedric wrote: From: Christopherson, Sean J Sent: Monday, June 03, 2019 10:16 AM On Sun, Jun 02, 2019 at 12:29:35AM -0700, Xing, Cedric wrote: Hi Sean, Generally I agree with your direction but think ALLOW_* flags are completely internal to LSM because they can be both

Re: [RFC PATCH 8/9] LSM: x86/sgx: Introduce ->enclave_load() hook for Intel SGX

On 6/3/19 10:42 AM, Sean Christopherson wrote: On Mon, Jun 03, 2019 at 10:19:18AM -0400, Stephen Smalley wrote: On 5/31/19 7:31 PM, Sean Christopherson wrote: enclave_load() is roughly analogous to the existing file_mprotect(). Due to the nature of SGX and its Enclave Page Cache (EPC), all

Re: [RFC PATCH 0/9] security: x86/sgx: SGX vs. LSM

On 6/2/19 3:29 AM, Xing, Cedric wrote: Hi Sean, From: Christopherson, Sean J Sent: Friday, May 31, 2019 4:32 PM This series is the result of a rather absurd amount of discussion over how to get SGX to play nice with LSM policies, without having to resort to evil shenanigans or put undue

Re: [RFC PATCH 9/9] security/selinux: Add enclave_load() implementation

On 5/31/19 7:31 PM, Sean Christopherson wrote: The goal of selinux_enclave_load() is to provide a facsimile of the existing selinux_file_mprotect() and file_map_prot_check() policies, but tailored to the unique properties of SGX. For example, an enclave page is technically backed by a

Re: [RFC PATCH 8/9] LSM: x86/sgx: Introduce ->enclave_load() hook for Intel SGX

On 5/31/19 7:31 PM, Sean Christopherson wrote: enclave_load() is roughly analogous to the existing file_mprotect(). Due to the nature of SGX and its Enclave Page Cache (EPC), all enclave VMAs are backed by a single file, i.e. /dev/sgx/enclave, that must be MAP_SHARED. Furthermore, all enclaves

Re: SGX vs LSM (Re: [PATCH v20 00/28] Intel SGX1 support)

On 5/30/19 10:31 AM, Andy Lutomirski wrote: Hi all- After an offline discussion with Sean yesterday, here are some updates to the user API parts of my proposal. Unfortunately, Sean convinced me that MAXPERM doesn't work the way I described it because, for SGX2, the enclave loader won't know at

Re: SGX vs LSM (Re: [PATCH v20 00/28] Intel SGX1 support)

On 5/30/19 2:12 AM, Xing, Cedric wrote: From: linux-sgx-ow...@vger.kernel.org [mailto:linux-sgx-ow...@vger.kernel.org] On Behalf Of Stephen Smalley Sent: Wednesday, May 29, 2019 7:08 AM On 5/28/19 4:24 PM, Sean Christopherson wrote: On Sat, May 25, 2019 at 11:09:38PM -0700, Xing, Cedric wrote

Re: SGX vs LSM (Re: [PATCH v20 00/28] Intel SGX1 support)

On 5/28/19 4:24 PM, Sean Christopherson wrote: On Sat, May 25, 2019 at 11:09:38PM -0700, Xing, Cedric wrote: From: Andy Lutomirski [mailto:l...@kernel.org] Sent: Saturday, May 25, 2019 5:58 PM On Sat, May 25, 2019 at 3:40 PM Xing, Cedric wrote: If we think of EADD as a way of mmap()'ing an

Re: SGX vs LSM (Re: [PATCH v20 00/28] Intel SGX1 support)

On 5/24/19 3:24 AM, Xing, Cedric wrote: Hi Andy, From: Andy Lutomirski [mailto:l...@kernel.org] Sent: Thursday, May 23, 2019 6:18 PM On Thu, May 23, 2019 at 4:40 PM Sean Christopherson wrote: On Thu, May 23, 2019 at 08:38:17AM -0700, Andy Lutomirski wrote: On Thu, May 23, 2019 at 7:17 AM

Re: SGX vs LSM (Re: [PATCH v20 00/28] Intel SGX1 support)

On 5/23/19 11:38 AM, Andy Lutomirski wrote: On Thu, May 23, 2019 at 7:17 AM Sean Christopherson wrote: On Thu, May 23, 2019 at 01:26:28PM +0300, Jarkko Sakkinen wrote: On Wed, May 22, 2019 at 07:35:17PM -0700, Sean Christopherson wrote: But actually, there's no need to disallow mmap() after

Re: [RFC] Turn lockdown into an LSM

On 5/22/19 3:19 PM, James Morris wrote: On Wed, 22 May 2019, Stephen Smalley wrote: That seems to violate the intent of lockdown as I understood it, and turns security_is_locked_down() into a finer-grained capable() call. Also, if I understand correctly, this could only be done if one were

Re: [RFC] Turn lockdown into an LSM

On 5/22/19 1:08 PM, Andy Lutomirski wrote: On Wed, May 22, 2019 at 9:49 AM Matthew Garrett wrote: On Tue, May 21, 2019 at 7:40 PM James Morris wrote: An LSM could also potentially implement its own policy for the hook. That was my plan. Right now the hook just gets an ASCII description of

Re: SGX vs LSM (Re: [PATCH v20 00/28] Intel SGX1 support)

On 5/22/19 9:22 AM, Jarkko Sakkinen wrote: On Wed, May 22, 2019 at 04:20:22PM +0300, Jarkko Sakkinen wrote: On Tue, May 21, 2019 at 08:51:40AM -0700, Sean Christopherson wrote: Except that mmap() is more or less required to guarantee that ELRANGE established by ECREATE is available. And we

Re: SGX vs LSM (Re: [PATCH v20 00/28] Intel SGX1 support)

On 5/17/19 4:14 PM, Andy Lutomirski wrote: On May 17, 2019, at 1:09 PM, Stephen Smalley wrote: On 5/17/19 3:28 PM, Sean Christopherson wrote: On Fri, May 17, 2019 at 02:05:39PM -0400, Stephen Smalley wrote: On 5/17/19 1:12 PM, Andy Lutomirski wrote: How can that work? Unless the API

Re: SGX vs LSM (Re: [PATCH v20 00/28] Intel SGX1 support)

On 5/17/19 3:28 PM, Sean Christopherson wrote: On Fri, May 17, 2019 at 02:05:39PM -0400, Stephen Smalley wrote: On 5/17/19 1:12 PM, Andy Lutomirski wrote: How can that work? Unless the API changes fairly radically, users fundamentally need to both write and execute the enclave. Some

Re: SGX vs LSM (Re: [PATCH v20 00/28] Intel SGX1 support)

On 5/17/19 2:05 PM, Stephen Smalley wrote: On 5/17/19 1:12 PM, Andy Lutomirski wrote: On May 17, 2019, at 9:37 AM, Stephen Smalley wrote: On 5/17/19 12:20 PM, Stephen Smalley wrote: On 5/17/19 11:09 AM, Sean Christopherson wrote: On Fri, May 17, 2019 at 09:53:06AM -0400, Stephen Smalley

Re: SGX vs LSM (Re: [PATCH v20 00/28] Intel SGX1 support)

On 5/17/19 1:50 PM, Sean Christopherson wrote: On Fri, May 17, 2019 at 01:42:50PM -0400, Stephen Smalley wrote: On 5/17/19 1:29 PM, Sean Christopherson wrote: AIUI, having FILE__WRITE and FILE__EXECUTE on /dev/sgx/enclave would allow *any* enclave/process to map EPC as RWX. Moving to anon

Re: SGX vs LSM (Re: [PATCH v20 00/28] Intel SGX1 support)

On 5/17/19 1:12 PM, Andy Lutomirski wrote: On May 17, 2019, at 9:37 AM, Stephen Smalley wrote: On 5/17/19 12:20 PM, Stephen Smalley wrote: On 5/17/19 11:09 AM, Sean Christopherson wrote: On Fri, May 17, 2019 at 09:53:06AM -0400, Stephen Smalley wrote: On 5/16/19 6:23 PM, Xing, Cedric

Re: SGX vs LSM (Re: [PATCH v20 00/28] Intel SGX1 support)

On 5/17/19 1:29 PM, Sean Christopherson wrote: On Fri, May 17, 2019 at 12:37:40PM -0400, Stephen Smalley wrote: On 5/17/19 12:20 PM, Stephen Smalley wrote: On 5/17/19 11:09 AM, Sean Christopherson wrote: I think we may want to change the SGX API to alloc an anon inode for each enclave instead

Re: SGX vs LSM (Re: [PATCH v20 00/28] Intel SGX1 support)

On 5/17/19 12:20 PM, Stephen Smalley wrote: On 5/17/19 11:09 AM, Sean Christopherson wrote: On Fri, May 17, 2019 at 09:53:06AM -0400, Stephen Smalley wrote: On 5/16/19 6:23 PM, Xing, Cedric wrote: I thought EXECMOD applied to files (and memory mappings backed by them) but I was probably wrong

Re: SGX vs LSM (Re: [PATCH v20 00/28] Intel SGX1 support)

On 5/17/19 11:09 AM, Sean Christopherson wrote: On Fri, May 17, 2019 at 09:53:06AM -0400, Stephen Smalley wrote: On 5/16/19 6:23 PM, Xing, Cedric wrote: I thought EXECMOD applied to files (and memory mappings backed by them) but I was probably wrong. It sounds like EXECMOD applies to the whole

Re: SGX vs LSM (Re: [PATCH v20 00/28] Intel SGX1 support)

On 5/16/19 6:23 PM, Xing, Cedric wrote: Hi Andy, SIGSTRUCT isn't necessarily stored on disk so may not always have a fd. How about the following? void *ss_pointer = mmap(sigstruct_fd, PROT_READ,...); ioctl(enclave_fd, SGX_INIT_THE_ENCLAVE, ss_pointer); The idea here is SIGSTRUCT will still

Re: kernel BUG at kernel/cred.c:434!

On 4/17/19 12:42 PM, Casey Schaufler wrote: On 4/17/2019 9:27 AM, Oleg Nesterov wrote: On 04/17, Paul Moore wrote: On Wed, Apr 17, 2019 at 10:57 AM Oleg Nesterov wrote: On 04/17, Paul Moore wrote: I'm tempted to simply return an error in selinux_setprocattr() if the task's credentials are

Re: Repost: Missing security_mmap_file() in remap_file_pages syscall

On 3/25/19 1:33 PM, TongZhang wrote: Dear Kernel Developers, We’d like to bring this up for a discussion again. Several months ago we posted an email discussing a case where remap_file_pages() has no security_mmap_file() check. At that time we were told that do_mmap_pgoff() will base the new

Re: [PATCH] selinux: fix NULL dereference in policydb_destroy()

;selinux: convert to kvmalloc") Signed-off-by: Ondrej Mosnacek Acked-by: Stephen Smalley --- security/selinux/ss/policydb.c | 13 + 1 file changed, 9 insertions(+), 4 deletions(-) NOTE: This applies directly on top of current Linus' tree, since the problematic commit i

Re: [PATCH] selinux: use kernel definition of PF_MAX in scripts

On 3/12/19 2:47 PM, Johannes Brechtmann wrote: From 1892b9ff8045bac6fe166802b2d8a8a3111c1e0c Mon Sep 17 00:00:00 2001 From: Johannes Brechtmann Date: Tue, 12 Mar 2019 17:50:12 +0100 Subject: [PATCH] selinux: use kernel definition of PF_MAX in scripts Building selinux scripts of old releases

Re: overlayfs access checks on underlying layers

On 3/4/19 12:01 PM, Mark Salyzyn wrote: On 11/29/2018 05:49 AM, Vivek Goyal wrote: So will override_creds=off solve the NFS issue also where all access will happen with the creds of task now? Though it will stil require more priviliges in task for other operations in overlay to succeed. NFS

Re: [RFC PATCH 04/27] containers: Allow a process to be forked into a container

On 2/15/19 11:07 AM, David Howells wrote: Allow a single process to be forked directly into a container using a new syscall, thereby 'booting' the container: pid_t pid = fork_into_container(int container_fd); This process will be the 'init' process of the container. Further attempts

Re: [RFC PATCH 22/27] KEYS: Replace uid/gid/perm permissions checking with an ACL

On 2/15/19 11:11 AM, David Howells wrote: Replace the uid/gid/perm permissions checking on a key with an ACL to allow the SETATTR and SEARCH permissions to be split. This will also allow a greater range of subjects to represented. WHY DO THIS? The problem is that

Re: [PATCH 06/10] security: fix documentation for the path_chmod hook

On 2/7/19 9:32 AM, Stephen Smalley wrote: On 2/7/19 9:09 AM, Edwin Zimmerman wrote: On Thursday, February 07, 2019 8:50 AM Al Viro wrote: On Thu, Feb 07, 2019 at 03:44:54PM +0300, Denis Efremov wrote: The path_chmod hook was changed in the commit "switch security_path_chmod() to struct

Re: [PATCH 06/10] security: fix documentation for the path_chmod hook

On 2/7/19 9:09 AM, Edwin Zimmerman wrote: On Thursday, February 07, 2019 8:50 AM Al Viro wrote: On Thu, Feb 07, 2019 at 03:44:54PM +0300, Denis Efremov wrote: The path_chmod hook was changed in the commit "switch security_path_chmod() to struct path *" (cdcf116d44e7). The argument @mnt was

Re: general protection fault in ebitmap_destroy

2: 888099d993c0 > R13: 0008 R14: 888099d993c0 R15: 88808967f648 > FS: 7f70cd9e5700() GS:8880ae70() > knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: 00000073c000 CR3: 96c4a000 CR4: 00

Re: overlayfs access checks on underlying layers

On 12/13/18 1:54 PM, Vivek Goyal wrote: On Thu, Dec 13, 2018 at 11:12:31AM -0500, Stephen Smalley wrote: [..] Can you elaborate a bit more on how this is leaking data through overlay mount. If it is, then why accessing file on lower is not equivalent of leaking of data. In the container use

Re: overlayfs access checks on underlying layers

On 12/13/18 9:58 AM, Vivek Goyal wrote: On Wed, Dec 12, 2018 at 09:51:59AM -0500, Stephen Smalley wrote: On 12/11/18 4:48 PM, Vivek Goyal wrote: On Thu, Dec 06, 2018 at 03:26:26PM -0500, Stephen Smalley wrote: On 12/5/18 8:43 AM, Vivek Goyal wrote: On Tue, Dec 04, 2018 at 11:49:16AM -0500

Re: overlayfs access checks on underlying layers

On 12/11/18 4:48 PM, Vivek Goyal wrote: On Thu, Dec 06, 2018 at 03:26:26PM -0500, Stephen Smalley wrote: On 12/5/18 8:43 AM, Vivek Goyal wrote: On Tue, Dec 04, 2018 at 11:49:16AM -0500, Stephen Smalley wrote: On 12/4/18 11:17 AM, Vivek Goyal wrote: On Tue, Dec 04, 2018 at 11:05:46AM -0500

Re: overlayfs access checks on underlying layers

On 12/5/18 8:43 AM, Vivek Goyal wrote: On Tue, Dec 04, 2018 at 11:49:16AM -0500, Stephen Smalley wrote: On 12/4/18 11:17 AM, Vivek Goyal wrote: On Tue, Dec 04, 2018 at 11:05:46AM -0500, Stephen Smalley wrote: On 12/4/18 10:42 AM, Vivek Goyal wrote: On Tue, Dec 04, 2018 at 04:31:09PM +0100

Re: overlayfs access checks on underlying layers

On 12/5/18 8:43 AM, Vivek Goyal wrote: On Tue, Dec 04, 2018 at 11:49:16AM -0500, Stephen Smalley wrote: On 12/4/18 11:17 AM, Vivek Goyal wrote: On Tue, Dec 04, 2018 at 11:05:46AM -0500, Stephen Smalley wrote: On 12/4/18 10:42 AM, Vivek Goyal wrote: On Tue, Dec 04, 2018 at 04:31:09PM +0100

Re: overlayfs access checks on underlying layers

On 12/4/18 11:17 AM, Vivek Goyal wrote: On Tue, Dec 04, 2018 at 11:05:46AM -0500, Stephen Smalley wrote: On 12/4/18 10:42 AM, Vivek Goyal wrote: On Tue, Dec 04, 2018 at 04:31:09PM +0100, Miklos Szeredi wrote: On Tue, Dec 4, 2018 at 4:22 PM Vivek Goyal wrote: Having said that, this still

Re: overlayfs access checks on underlying layers

On 12/4/18 11:17 AM, Vivek Goyal wrote: On Tue, Dec 04, 2018 at 11:05:46AM -0500, Stephen Smalley wrote: On 12/4/18 10:42 AM, Vivek Goyal wrote: On Tue, Dec 04, 2018 at 04:31:09PM +0100, Miklos Szeredi wrote: On Tue, Dec 4, 2018 at 4:22 PM Vivek Goyal wrote: Having said that, this still

Re: overlayfs access checks on underlying layers

On 12/4/18 10:42 AM, Vivek Goyal wrote: On Tue, Dec 04, 2018 at 04:31:09PM +0100, Miklos Szeredi wrote: On Tue, Dec 4, 2018 at 4:22 PM Vivek Goyal wrote: Having said that, this still create little anomaly when mknod to client is not allowed on context label. So a device file, which is on

Re: overlayfs access checks on underlying layers

On 12/4/18 10:42 AM, Vivek Goyal wrote: On Tue, Dec 04, 2018 at 04:31:09PM +0100, Miklos Szeredi wrote: On Tue, Dec 4, 2018 at 4:22 PM Vivek Goyal wrote: Having said that, this still create little anomaly when mknod to client is not allowed on context label. So a device file, which is on

Re: overlayfs access checks on underlying layers

On 12/4/18 9:45 AM, Miklos Szeredi wrote: On Tue, Dec 4, 2018 at 3:28 PM Stephen Smalley wrote: On 12/4/18 8:32 AM, Miklos Szeredi wrote: My proposed sequence would be a) check task's creds against overlay inode, fail -> return fail, otherwise: b) check mounter's creds against lower in

Re: overlayfs access checks on underlying layers

On 12/4/18 9:45 AM, Miklos Szeredi wrote: On Tue, Dec 4, 2018 at 3:28 PM Stephen Smalley wrote: On 12/4/18 8:32 AM, Miklos Szeredi wrote: My proposed sequence would be a) check task's creds against overlay inode, fail -> return fail, otherwise: b) check mounter's creds against lower in

Re: overlayfs access checks on underlying layers

On 12/4/18 10:15 AM, Vivek Goyal wrote: On Tue, Dec 04, 2018 at 09:30:53AM -0500, Stephen Smalley wrote: On 12/4/18 8:32 AM, Miklos Szeredi wrote: On Thu, Nov 29, 2018 at 10:16 PM Stephen Smalley wrote: On 11/29/18 4:03 PM, Stephen Smalley wrote: On 11/29/18 2:47 PM, Miklos Szeredi wrote

Re: overlayfs access checks on underlying layers

On 12/4/18 10:15 AM, Vivek Goyal wrote: On Tue, Dec 04, 2018 at 09:30:53AM -0500, Stephen Smalley wrote: On 12/4/18 8:32 AM, Miklos Szeredi wrote: On Thu, Nov 29, 2018 at 10:16 PM Stephen Smalley wrote: On 11/29/18 4:03 PM, Stephen Smalley wrote: On 11/29/18 2:47 PM, Miklos Szeredi wrote

Re: overlayfs access checks on underlying layers

On 12/3/18 6:27 PM, Paul Moore wrote: On Thu, Nov 29, 2018 at 5:22 PM Daniel Walsh wrote: On 11/29/18 2:47 PM, Miklos Szeredi wrote: On Thu, Nov 29, 2018 at 5:14 PM Stephen Smalley wrote: Possibly I misunderstood you, but I don't think we want to copy-up on permission denial, as that would

Re: overlayfs access checks on underlying layers

On 12/3/18 6:27 PM, Paul Moore wrote: On Thu, Nov 29, 2018 at 5:22 PM Daniel Walsh wrote: On 11/29/18 2:47 PM, Miklos Szeredi wrote: On Thu, Nov 29, 2018 at 5:14 PM Stephen Smalley wrote: Possibly I misunderstood you, but I don't think we want to copy-up on permission denial, as that would

Re: overlayfs access checks on underlying layers

On 12/4/18 8:32 AM, Miklos Szeredi wrote: On Thu, Nov 29, 2018 at 10:16 PM Stephen Smalley wrote: On 11/29/18 4:03 PM, Stephen Smalley wrote: On 11/29/18 2:47 PM, Miklos Szeredi wrote: On Thu, Nov 29, 2018 at 5:14 PM Stephen Smalley wrote: Possibly I misunderstood you, but I don't think

Re: overlayfs access checks on underlying layers

On 12/4/18 8:32 AM, Miklos Szeredi wrote: On Thu, Nov 29, 2018 at 10:16 PM Stephen Smalley wrote: On 11/29/18 4:03 PM, Stephen Smalley wrote: On 11/29/18 2:47 PM, Miklos Szeredi wrote: On Thu, Nov 29, 2018 at 5:14 PM Stephen Smalley wrote: Possibly I misunderstood you, but I don't think

Re: overlayfs access checks on underlying layers

On 11/29/18 4:03 PM, Stephen Smalley wrote: On 11/29/18 2:47 PM, Miklos Szeredi wrote: On Thu, Nov 29, 2018 at 5:14 PM Stephen Smalley wrote: Possibly I misunderstood you, but I don't think we want to copy-up on permission denial, as that would still allow the mounter to read/write special

Re: overlayfs access checks on underlying layers

On 11/29/18 4:03 PM, Stephen Smalley wrote: On 11/29/18 2:47 PM, Miklos Szeredi wrote: On Thu, Nov 29, 2018 at 5:14 PM Stephen Smalley wrote: Possibly I misunderstood you, but I don't think we want to copy-up on permission denial, as that would still allow the mounter to read/write special

Re: overlayfs access checks on underlying layers

On 11/29/18 2:47 PM, Miklos Szeredi wrote: On Thu, Nov 29, 2018 at 5:14 PM Stephen Smalley wrote: Possibly I misunderstood you, but I don't think we want to copy-up on permission denial, as that would still allow the mounter to read/write special files or execute regular files to which

Re: overlayfs access checks on underlying layers

On 11/29/18 2:47 PM, Miklos Szeredi wrote: On Thu, Nov 29, 2018 at 5:14 PM Stephen Smalley wrote: Possibly I misunderstood you, but I don't think we want to copy-up on permission denial, as that would still allow the mounter to read/write special files or execute regular files to which

Re: overlayfs access checks on underlying layers

On 11/29/18 6:04 AM, Miklos Szeredi wrote: On Wed, Nov 28, 2018 at 10:43 PM Stephen Smalley wrote: On 11/28/18 3:24 PM, Miklos Szeredi wrote: On Wed, Nov 28, 2018 at 8:32 PM Stephen Smalley wrote: [...] Does the breaking commit (007ea44892e6) fix a real bug affecting users

Re: overlayfs access checks on underlying layers

On 11/29/18 6:04 AM, Miklos Szeredi wrote: On Wed, Nov 28, 2018 at 10:43 PM Stephen Smalley wrote: On 11/28/18 3:24 PM, Miklos Szeredi wrote: On Wed, Nov 28, 2018 at 8:32 PM Stephen Smalley wrote: [...] Does the breaking commit (007ea44892e6) fix a real bug affecting users

Re: overlayfs access checks on underlying layers

On 11/29/18 11:16 AM, Stephen Smalley wrote: On 11/29/18 6:04 AM, Miklos Szeredi wrote: On Wed, Nov 28, 2018 at 10:43 PM Stephen Smalley wrote: On 11/28/18 3:24 PM, Miklos Szeredi wrote: On Wed, Nov 28, 2018 at 8:32 PM Stephen Smalley wrote: [...] Does the breaking commit (007ea44892e6

Re: overlayfs access checks on underlying layers

On 11/29/18 11:16 AM, Stephen Smalley wrote: On 11/29/18 6:04 AM, Miklos Szeredi wrote: On Wed, Nov 28, 2018 at 10:43 PM Stephen Smalley wrote: On 11/28/18 3:24 PM, Miklos Szeredi wrote: On Wed, Nov 28, 2018 at 8:32 PM Stephen Smalley wrote: [...] Does the breaking commit (007ea44892e6

Re: overlayfs access checks on underlying layers

On 11/28/18 3:24 PM, Miklos Szeredi wrote: On Wed, Nov 28, 2018 at 8:32 PM Stephen Smalley wrote: On 11/28/18 12:03 PM, Vivek Goyal wrote: On Wed, Nov 28, 2018 at 11:00:09AM +0100, Miklos Szeredi wrote: On Tue, Nov 27, 2018 at 10:05 PM Vivek Goyal wrote: On Tue, Nov 27, 2018 at 08:58

Re: overlayfs access checks on underlying layers

On 11/28/18 3:24 PM, Miklos Szeredi wrote: On Wed, Nov 28, 2018 at 8:32 PM Stephen Smalley wrote: On 11/28/18 12:03 PM, Vivek Goyal wrote: On Wed, Nov 28, 2018 at 11:00:09AM +0100, Miklos Szeredi wrote: On Tue, Nov 27, 2018 at 10:05 PM Vivek Goyal wrote: On Tue, Nov 27, 2018 at 08:58

Re: overlayfs access checks on underlying layers

On 11/28/18 12:03 PM, Vivek Goyal wrote: On Wed, Nov 28, 2018 at 11:00:09AM +0100, Miklos Szeredi wrote: On Tue, Nov 27, 2018 at 10:05 PM Vivek Goyal wrote: On Tue, Nov 27, 2018 at 08:58:06PM +0100, Miklos Szeredi wrote: [resending with fixed email address for Paul Moore] Moving discussion

Re: overlayfs access checks on underlying layers

On 11/28/18 12:03 PM, Vivek Goyal wrote: On Wed, Nov 28, 2018 at 11:00:09AM +0100, Miklos Szeredi wrote: On Tue, Nov 27, 2018 at 10:05 PM Vivek Goyal wrote: On Tue, Nov 27, 2018 at 08:58:06PM +0100, Miklos Szeredi wrote: [resending with fixed email address for Paul Moore] Moving discussion

Re: [PATCH v7 1/3] x86/speculation: apply IBPB more strictly to avoid cross-process data leak

On 09/25/2018 08:38 AM, Jiri Kosina wrote: From: Jiri Kosina Currently, we are issuing IBPB only in cases when switching into a non-dumpable process, the rationale being to protect such 'important and security sensitive' processess (such as GPG) from data leak into a different userspace

Re: [PATCH v7 1/3] x86/speculation: apply IBPB more strictly to avoid cross-process data leak

On 09/25/2018 08:38 AM, Jiri Kosina wrote: From: Jiri Kosina Currently, we are issuing IBPB only in cases when switching into a non-dumpable process, the rationale being to protect such 'important and security sensitive' processess (such as GPG) from data leak into a different userspace

Re: [PATCH v5 3/5] SELinux: Prepare for PTRACE_MODE_SCHED

On 09/26/2018 04:34 PM, Casey Schaufler wrote: From: Casey Schaufler A ptrace access check with mode PTRACE_MODE_SCHED gets called from process switching code. This precludes the use of audit or avc, as the locking is incompatible. The only available check that can be made without using avc is

Re: [PATCH v5 3/5] SELinux: Prepare for PTRACE_MODE_SCHED

On 09/26/2018 04:34 PM, Casey Schaufler wrote: From: Casey Schaufler A ptrace access check with mode PTRACE_MODE_SCHED gets called from process switching code. This precludes the use of audit or avc, as the locking is incompatible. The only available check that can be made without using avc is

Re: Leaking Path in XFS's ioctl interface(missing LSM check)

On 09/25/2018 09:33 PM, Dave Chinner wrote: On Tue, Sep 25, 2018 at 08:51:50PM -0400, TongZhang wrote: Hi, I'm bringing up this issue again to let of LSM developers know the situation, and would like to know your thoughts. Several weeks ago I sent an email to the security list to discuss the

Re: Leaking Path in XFS's ioctl interface(missing LSM check)

On 09/25/2018 09:33 PM, Dave Chinner wrote: On Tue, Sep 25, 2018 at 08:51:50PM -0400, TongZhang wrote: Hi, I'm bringing up this issue again to let of LSM developers know the situation, and would like to know your thoughts. Several weeks ago I sent an email to the security list to discuss the

Re: Leaking path for search_binary_handler

On 09/25/2018 01:27 PM, Tong Zhang wrote: Kernel Version: 4.18.5 Problem Description: search_binary_handler() should be called after setting bprm using prepare_binprm(), and in prepare_binprm(), there’s a LSM hook security_bprm_set_creds(), which can make a decision that binfmt cares. We

Re: Leaking path for search_binary_handler

On 09/25/2018 01:27 PM, Tong Zhang wrote: Kernel Version: 4.18.5 Problem Description: search_binary_handler() should be called after setting bprm using prepare_binprm(), and in prepare_binprm(), there’s a LSM hook security_bprm_set_creds(), which can make a decision that binfmt cares. We

Re: leaking path in android binder: set_nice

On 09/25/2018 01:27 PM, Tong Zhang wrote: Kernel Version: 4.18.5 Problem Description: When setting nice value, it is checked by LSM function security_task_setnice(). see kernel/sched/core.c:3972 SYSCALL_DEFINE1(nice, int, increment) We discovered a leaking path in android binder which allows

Re: leaking path in android binder: set_nice

On 09/25/2018 01:27 PM, Tong Zhang wrote: Kernel Version: 4.18.5 Problem Description: When setting nice value, it is checked by LSM function security_task_setnice(). see kernel/sched/core.c:3972 SYSCALL_DEFINE1(nice, int, increment) We discovered a leaking path in android binder which allows

Re: [PATCH v4 00/19] LSM: Module stacking for SARA and Landlock

On 09/23/2018 01:09 PM, Casey Schaufler wrote: On 9/23/2018 8:59 AM, Tetsuo Handa wrote: On 2018/09/23 11:43, Kees Cook wrote: I'm excited about getting this landed! Soon. Real soon. I hope. I would very much like for someone from the SELinux camp to chime in, especially on the

Re: [PATCH v4 00/19] LSM: Module stacking for SARA and Landlock

On 09/23/2018 01:09 PM, Casey Schaufler wrote: On 9/23/2018 8:59 AM, Tetsuo Handa wrote: On 2018/09/23 11:43, Kees Cook wrote: I'm excited about getting this landed! Soon. Real soon. I hope. I would very much like for someone from the SELinux camp to chime in, especially on the

Re: [RFC PATCH] selinux: add a fallback to defcontext for native labeling

On 09/19/2018 12:52 PM, Taras Kondratiuk wrote: When files on NFSv4 server are not properly labeled (label doesn't match a policy on a client) they will end up with unlabeled_t type which is too generic. We would like to be able to set a default context per mount. 'defcontext' mount option looks

Re: [RFC PATCH] selinux: add a fallback to defcontext for native labeling

On 09/19/2018 12:52 PM, Taras Kondratiuk wrote: When files on NFSv4 server are not properly labeled (label doesn't match a policy on a client) they will end up with unlabeled_t type which is too generic. We would like to be able to set a default context per mount. 'defcontext' mount option looks

Re: WARNING in apparmor_secid_to_secctx

On 08/31/2018 12:07 PM, Paul Moore wrote: On Fri, Aug 31, 2018 at 12:01 PM Stephen Smalley wrote: On 08/29/2018 10:21 PM, Dmitry Vyukov wrote: On Wed, Aug 29, 2018 at 7:17 PM, syzbot wrote: Hello, syzbot found the following crash on: HEAD commit:817e60a7a2bb Merge branch 'nfp-add

Re: WARNING in apparmor_secid_to_secctx

On 08/31/2018 12:07 PM, Paul Moore wrote: On Fri, Aug 31, 2018 at 12:01 PM Stephen Smalley wrote: On 08/29/2018 10:21 PM, Dmitry Vyukov wrote: On Wed, Aug 29, 2018 at 7:17 PM, syzbot wrote: Hello, syzbot found the following crash on: HEAD commit:817e60a7a2bb Merge branch 'nfp-add

Re: WARNING in apparmor_secid_to_secctx

On 08/31/2018 12:16 PM, Stephen Smalley wrote: On 08/31/2018 12:07 PM, Paul Moore wrote: On Fri, Aug 31, 2018 at 12:01 PM Stephen Smalley wrote: On 08/29/2018 10:21 PM, Dmitry Vyukov wrote: On Wed, Aug 29, 2018 at 7:17 PM, syzbot wrote: Hello, syzbot found the following crash on: HEAD

Re: WARNING in apparmor_secid_to_secctx

On 08/31/2018 12:16 PM, Stephen Smalley wrote: On 08/31/2018 12:07 PM, Paul Moore wrote: On Fri, Aug 31, 2018 at 12:01 PM Stephen Smalley wrote: On 08/29/2018 10:21 PM, Dmitry Vyukov wrote: On Wed, Aug 29, 2018 at 7:17 PM, syzbot wrote: Hello, syzbot found the following crash on: HEAD

Re: WARNING in apparmor_secid_to_secctx

On 08/29/2018 10:21 PM, Dmitry Vyukov wrote: On Wed, Aug 29, 2018 at 7:17 PM, syzbot wrote: Hello, syzbot found the following crash on: HEAD commit:817e60a7a2bb Merge branch 'nfp-add-NFP5000-support' git tree: net-next console output:

Re: WARNING in apparmor_secid_to_secctx

On 08/29/2018 10:21 PM, Dmitry Vyukov wrote: On Wed, Aug 29, 2018 at 7:17 PM, syzbot wrote: Hello, syzbot found the following crash on: HEAD commit:817e60a7a2bb Merge branch 'nfp-add-NFP5000-support' git tree: net-next console output:

Re: [PATCH 20/23] LSM: Move common usercopy into

On 05/14/2018 11:12 AM, Stephen Smalley wrote: > On 05/10/2018 08:55 PM, Casey Schaufler wrote: >> From: Casey Schaufler <ca...@schaufler-ca.com> >> Date: Thu, 10 May 2018 15:54:25 -0700 >> Subject: [PATCH 20/23] LSM: Move common usercopy into >> security_ge

Re: [PATCH 20/23] LSM: Move common usercopy into

On 05/14/2018 11:12 AM, Stephen Smalley wrote: > On 05/10/2018 08:55 PM, Casey Schaufler wrote: >> From: Casey Schaufler >> Date: Thu, 10 May 2018 15:54:25 -0700 >> Subject: [PATCH 20/23] LSM: Move common usercopy into >> security_getpeersec_stream >>

Re: [PATCH 20/23] LSM: Move common usercopy into

On 05/10/2018 08:55 PM, Casey Schaufler wrote: > From: Casey Schaufler > Date: Thu, 10 May 2018 15:54:25 -0700 > Subject: [PATCH 20/23] LSM: Move common usercopy into > security_getpeersec_stream > > The modules implementing hook for getpeersec_stream > don't need to be

Re: [PATCH 20/23] LSM: Move common usercopy into

On 05/10/2018 08:55 PM, Casey Schaufler wrote: > From: Casey Schaufler > Date: Thu, 10 May 2018 15:54:25 -0700 > Subject: [PATCH 20/23] LSM: Move common usercopy into > security_getpeersec_stream > > The modules implementing hook for getpeersec_stream > don't need to be duplicating the

Re: [PATCH 10/23] LSM: Infrastructure management of the inode security

On 05/10/2018 08:53 PM, Casey Schaufler wrote: > From: Casey Schaufler > Date: Thu, 10 May 2018 14:23:27 -0700 > Subject: [PATCH 10/23] LSM: Infrastructure management of the inode security > blob > > Move management of the inode->i_security blob out > of the individual

Re: [PATCH 10/23] LSM: Infrastructure management of the inode security

On 05/10/2018 08:53 PM, Casey Schaufler wrote: > From: Casey Schaufler > Date: Thu, 10 May 2018 14:23:27 -0700 > Subject: [PATCH 10/23] LSM: Infrastructure management of the inode security > blob > > Move management of the inode->i_security blob out > of the individual security modules and into

Re: [PATCH 04/24] VFS: Add LSM hooks for filesystem context [ver #7]

On 04/24/2018 11:22 AM, David Howells wrote: > Stephen Smalley <s...@tycho.nsa.gov> wrote: > >> Neither fsopen() nor fscontext_fs_write() appear to perform any kind of >> up-front permission checking (DAC or MAC), although some security hooks may >> be ultimately

Re: [PATCH 04/24] VFS: Add LSM hooks for filesystem context [ver #7]

On 04/24/2018 11:22 AM, David Howells wrote: > Stephen Smalley wrote: > >> Neither fsopen() nor fscontext_fs_write() appear to perform any kind of >> up-front permission checking (DAC or MAC), although some security hooks may >> be ultimately called to allocate structures

Re: [PATCH 9/9] Protect SELinux initialized state with pmalloc

On 04/23/2018 08:54 AM, Igor Stoppa wrote: > SELinux is one of the primary targets, when a system running it comes > under attack. > > The reason is that, even if an attacker ishould manage to gain root, > SELinux will still prevent most desirable actions. > > Even in a fully locked down system,

<    1   2   3   4   5   6   7   8   9   10   >