Re: [PATCH v4 4/4] vduse: Add LSM hooks to check Virtio device type

"Michael S. Tsirkin" wrote: This patch introduces LSM hooks for devices creation, destruction and opening operations, checking the application is allowed to perform these operations for the Virtio device type. Signed-off-by: Maxime Coquelin --- drivers/vdpa/vdpa_user/vduse_d

Re: [PATCH v4 4/4] vduse: Add LSM hooks to check Virtio device type

gt; > > > On Oct 20, 2023 "Michael S. Tsirkin" wrote: > > > > > > > > > > This patch introduces LSM hooks for devices creation, > > > > > destruction and opening operations, checking the > > > > > application is a

Re: [PATCH v4 4/4] vduse: Add LSM hooks to check Virtio device type

On 12/8/23 12:05, Michael S. Tsirkin wrote: On Fri, Dec 08, 2023 at 12:01:15PM +0100, Maxime Coquelin wrote: Hello Paul, On 11/8/23 03:31, Paul Moore wrote: On Oct 20, 2023 "Michael S. Tsirkin" wrote: This patch introduces LSM hooks for devices creation, destruction a

Re: [PATCH v4 4/4] vduse: Add LSM hooks to check Virtio device type

On Fri, Dec 08, 2023 at 12:01:15PM +0100, Maxime Coquelin wrote: > Hello Paul, > > On 11/8/23 03:31, Paul Moore wrote: > > On Oct 20, 2023 "Michael S. Tsirkin" wrote: > > > > > > This patch introduces LSM hooks for devices creation, > &g

Re: [PATCH v4 4/4] vduse: Add LSM hooks to check Virtio device type

Hello Paul, On 11/8/23 03:31, Paul Moore wrote: On Oct 20, 2023 "Michael S. Tsirkin" wrote: This patch introduces LSM hooks for devices creation, destruction and opening operations, checking the application is allowed to perform these operations for the Virtio device type.

Re: [PATCH v4 4/4] vduse: Add LSM hooks to check Virtio device type

On Oct 20, 2023 "Michael S. Tsirkin" wrote: > > This patch introduces LSM hooks for devices creation, > destruction and opening operations, checking the > application is allowed to perform these operations for > the Virtio device type. > > Signed-off-by: Maxime

Re: [PATCH v2] bpf: Drop disabled LSM hooks from the sleepable set

Hello: This patch was applied to bpf/bpf.git (refs/heads/master): On Mon, 25 Jan 2021 08:39:36 +0200 you wrote: > Some networking and keys LSM hooks are conditionally enabled > and when building the new sleepable BPF LSM hooks with those > LSM hooks disabled, the following build err

Re: [PATCH v2] bpf: Drop disabled LSM hooks from the sleepable set

On Mon, Jan 25, 2021 at 7:39 AM Mikko Ylinen wrote: > > Some networking and keys LSM hooks are conditionally enabled > and when building the new sleepable BPF LSM hooks with those > LSM hooks disabled, the following build error occurs: > > BTFIDS vmlinux > FAI

Re: [PATCH] bpf: Drop disabled LSM hooks from the sleepable set

On Mon, Jan 25, 2021 at 7:55 AM Mikko Ylinen wrote: > > On Sat, Jan 23, 2021 at 12:50:21AM +0100, KP Singh wrote: > > On Fri, Jan 22, 2021 at 11:33 PM KP Singh wrote: > > > > > > On Fri, Jan 22, 2021 at 1:32 PM Mikko Ylinen > > > wrote: > > >

[PATCH v2] bpf: Drop disabled LSM hooks from the sleepable set

Some networking and keys LSM hooks are conditionally enabled and when building the new sleepable BPF LSM hooks with those LSM hooks disabled, the following build error occurs: BTFIDS vmlinux FAILED unresolved symbol bpf_lsm_socket_socketpair To fix the error, conditionally add the relevant

Re: [PATCH] bpf: Drop disabled LSM hooks from the sleepable set

On Sat, Jan 23, 2021 at 12:50:21AM +0100, KP Singh wrote: > On Fri, Jan 22, 2021 at 11:33 PM KP Singh wrote: > > > > On Fri, Jan 22, 2021 at 1:32 PM Mikko Ylinen > > wrote: > > > > > > Networking LSM hooks are conditionally enabled and when buildin

Re: [PATCH] bpf: Drop disabled LSM hooks from the sleepable set

On Fri, Jan 22, 2021 at 11:33 PM KP Singh wrote: > > On Fri, Jan 22, 2021 at 1:32 PM Mikko Ylinen > wrote: > > > > Networking LSM hooks are conditionally enabled and when building the new > > sleepable BPF LSM hooks with the networking LSM hooks disabled, the >

Re: [PATCH] bpf: Drop disabled LSM hooks from the sleepable set

On Fri, Jan 22, 2021 at 1:32 PM Mikko Ylinen wrote: > > Networking LSM hooks are conditionally enabled and when building the new > sleepable BPF LSM hooks with the networking LSM hooks disabled, the > following build error occurs: > > BTFIDS vmlinux > FAI

[PATCH] bpf: Drop disabled LSM hooks from the sleepable set

Networking LSM hooks are conditionally enabled and when building the new sleepable BPF LSM hooks with the networking LSM hooks disabled, the following build error occurs: BTFIDS vmlinux FAILED unresolved symbol bpf_lsm_socket_socketpair To fix the error, conditionally add the networking LSM

Re: [PATCH v4 0/2] security: add fault injection to LSM hooks

interfaces to return error > codes. This patch series proposes adding such fault injection > capability into LSM hooks. > > The intent is to make it possible to test whether the existing kernel > code properly handles negative return values of LSM hooks. Syzbot > [https://githu

Re: [PATCH bpf-next 2/2] bpf: Expose bpf_d_path helper to sleepable LSM hooks

programs and merely uses the list of sleeable hooks as the initial subset of LSM hooks where it can sleeable => sleepable probably not need to resend if no other major changes. The maintainer can just fix it up before merging. Did while rebasing & applying, thanks everyone! be used. Sig

Re: [PATCH bpf-next 2/2] bpf: Expose bpf_d_path helper to sleepable LSM hooks

hooks as the initial subset of LSM hooks where it can sleeable => sleepable probably not need to resend if no other major changes. The maintainer can just fix it up before merging. be used. Signed-off-by: KP Singh Acked-by: Yonghong Song

[PATCH bpf-next v3 1/2] bpf: Augment the set of sleepable LSM hooks

program can be attached to these LSM hooks. A new helper method bpf_lsm_is_sleepable_hook is added and the set is maintained locally in bpf_lsm.c Signed-off-by: KP Singh --- include/linux/bpf_lsm.h | 7 kernel/bpf/bpf_lsm.c| 81 + kernel/bpf/verifier.c

[PATCH bpf-next v3 0/2] Sleepable LSM Hooks

ugment the set of sleepable LSM hooks bpf: Expose bpf_d_path helper to sleepable LSM hooks include/linux/bpf_lsm.h | 7 kernel/bpf/bpf_lsm.c | 81 kernel/bpf/verifier.c| 16 +--- kernel/trace/bpf_trace.c | 7 +++- 4 files changed, 95 inse

[PATCH bpf-next v3 2/2] bpf: Expose bpf_d_path helper to sleepable LSM hooks

From: KP Singh Sleepable hooks are never called from an NMI/interrupt context, so it is safe to use the bpf_d_path helper in LSM programs attaching to these hooks. The helper is not restricted to sleepable programs and merely uses the list of sleeable hooks as the initial subset of LSM hooks

Re: [PATCH bpf-next v2 1/2] bpf: Augment the set of sleepable LSM hooks

d idea! At the very least, we can update the comments in lsm_hooks.h which already mention some of the LSM hooks as being called from non-sleepable contexts. I will remove this comment, send a separate patch to security folks and respin these patches. -KP > + > static bool __

Re: [PATCH bpf-next v2 1/2] bpf: Augment the set of sleepable LSM hooks

This means that a sleepable LSM eBPF program can be attached to these LSM hooks. A new helper method bpf_lsm_is_sleepable_hook is added and the set is maintained locally in bpf_lsm.c A comment is added about the list of LSM hooks that have been observed to be called from softirqs, atomic contexts

Re: [PATCH bpf-next v2 0/2] Sleepable LSM Hooks

On Thu, Nov 12, 2020 at 9:03 PM KP Singh wrote: > > From: KP Singh > > # v1 -> v2 > > * Fixed typos and formatting errors. > * Added Andrii's ack. Oops, I sent an older patch file which does not have Andrii's ack.

[PATCH bpf-next v2 0/2] Sleepable LSM Hooks

From: KP Singh # v1 -> v2 * Fixed typos and formatting errors. * Added Andrii's ack. KP Singh (2): bpf: Augment the set of sleepable LSM hooks bpf: Expose bpf_d_path helper to sleepable LSM hooks include/linux/bpf_lsm.h | 7 +++ kernel/bpf/bpf_lsm.c |

[PATCH bpf-next v2 2/2] bpf: Expose bpf_d_path helper to sleepable LSM hooks

From: KP Singh Sleepable hooks are never called from an NMI/interrupt context, so it is safe to use the bpf_d_path helper in LSM programs attaching to these hooks. The helper is not restricted to sleepable programs and merely uses the list of sleeable hooks as the initial subset of LSM hooks

[PATCH bpf-next v2 1/2] bpf: Augment the set of sleepable LSM hooks

program can be attached to these LSM hooks. A new helper method bpf_lsm_is_sleepable_hook is added and the set is maintained locally in bpf_lsm.c A comment is added about the list of LSM hooks that have been observed to be called from softirqs, atomic contexts, or the ones that can trigger pagefaults

Re: [PATCH bpf-next 1/2] bpf: Augment the set of sleepable LSM hooks

d with the correct kernel > > config options enabled, i.e. > > > > DEBUG_ATOMIC_SLEEP=y > > LOCKDEP=y > > PROVE_LOCKING=y > > > > This means that a sleepable LSM eBPF prorgam can be attached to these > > typo: program Fixed. >

Re: [PATCH bpf-next 2/2] bpf: Expose bpf_d_path helper to sleepable LSM hooks

programs and merely uses the > list of sleeable hooks as the initial subset of LSM hooks where it can > be used. > > Signed-off-by: KP Singh > --- LGTM. Acked-by: Andrii Nakryiko > kernel/trace/bpf_trace.c | 7 ++- > 1 file changed, 6 insertions(+), 1 deletion(-) >

Re: [PATCH bpf-next 1/2] bpf: Augment the set of sleepable LSM hooks

EP=y > LOCKDEP=y > PROVE_LOCKING=y > > This means that a sleepable LSM eBPF prorgam can be attached to these typo: program > LSM hooks. A new helper method bpf_lsm_is_sleepable_hook is added and > the set is maintained locally in bpf_lsm.c > > A comment is

[PATCH bpf-next 2/2] bpf: Expose bpf_d_path helper to sleepable LSM hooks

From: KP Singh Sleepable hooks are never called from an NMI/interrupt context, so it is safe to use the bpf_d_path helper in LSM programs attaching to these hooks. The helper is not restricted to sleepable programs and merely uses the list of sleeable hooks as the initial subset of LSM hooks

[PATCH bpf-next 1/2] bpf: Augment the set of sleepable LSM hooks

prorgam can be attached to these LSM hooks. A new helper method bpf_lsm_is_sleepable_hook is added and the set is maintained locally in bpf_lsm.c A comment is added about the list of LSM hooks that have been observed to be called from softirqs, atomic contexts, or the ones that can trigger pagefaults

[PATCH v4 0/2] security: add fault injection to LSM hooks

capability into LSM hooks. The intent is to make it possible to test whether the existing kernel code properly handles negative return values of LSM hooks. Syzbot [https://github.com/google/syzkaller/blob/master/docs/syzbot.md] will automatically do that with the aid of instrumentation tools once

Re: [PATCH v3 0/2] security: add fault injection to LSM hooks

sting of the stability of the Linux kernel by providing > > means to force a number of kernel interfaces to return error > > codes. This patch series proposes adding such fault injection > > capability into LSM hooks. > > > > The intent is to make it possible to test whether the

Re: [PATCH v3 0/2] security: add fault injection to LSM hooks

interfaces to return error > codes. This patch series proposes adding such fault injection > capability into LSM hooks. > > The intent is to make it possible to test whether the existing kernel > code properly handles negative return values of LSM hooks. Syzbot > [https://githu

[PATCH v3 0/2] security: add fault injection to LSM hooks

capability into LSM hooks. The intent is to make it possible to test whether the existing kernel code properly handles negative return values of LSM hooks. Syzbot [https://github.com/google/syzkaller/blob/master/docs/syzbot.md] will automatically do that with the aid of instrumentation tools once

[RFC PATCH v2 0/2] security: add fault injection to LSM hooks

into LSM hooks. The intent is to make it possible to test whether the existing kernel code properly handles negative return values of LSM hooks. Syzbot [https://github.com/google/syzkaller/blob/master/docs/syzbot.md] will automatically do that with the aid of instrumentation tools once

[RFC PATCH 0/1] security: add fault injection to LSM hooks

into LSM hooks. The intent is to make it possible to test whether the existing kernel code properly handles negative return values of LSM hooks. Syzbot [https://github.com/google/syzkaller/blob/master/docs/syzbot.md] will automatically do that with the aid of instrumentation tools once

Re: [RFC PATCH v1 0/3] security/x86/sgx: SGX specific LSM hooks

vm_file, > linear_address } can be used to uniquely identify an enclave page. Then by > notifying LSM on creation of every enclave page (via a new LSM hook - > security_enclave_load), LSM modules would be able to track origin and > protection changes of every page, hence be able to

[RFC PATCH v1 1/3] LSM/x86/sgx: Add SGX specific LSM hooks

This patch has made two changes to LSM hooks. The first change is the addition of two new SGX specific LSM hooks. security_enclave_load() - is called whenever new EPC pages are added to an enclave, so that an LSM module could initialize internal states for those pages. An LSM module may track

[RFC PATCH v1 0/3] security/x86/sgx: SGX specific LSM hooks

le to track origin and protection changes of every page, hence be able to judge correctly upon mmap/mprotect requests. Cedric Xing (3): LSM/x86/sgx: Add SGX specific LSM hooks LSM/x86/sgx: Implement SGX specific hooks in SELinux LSM/x86/sgx: Call new LSM hooks from SGX subsystem arch/x86/kerne

[RFC PATCH v1 3/3] LSM/x86/sgx: Call new LSM hooks from SGX subsystem

There are three places LSM hooks are called from within the SGX subsystem. The first place is to invoke security_file_mprotect() in sgx_mmap() to validate requested protection. Given the architecture of SGX subsystem, all enclaves look like file mappings of /dev/sgx/enclave device file, meaning

[PATCH 08/34] vfs: Add LSM hooks for the new mount API [ver #12]

Add LSM hooks for use by the new mount API and filesystem context code. This includes: (1) Hooks to handle allocation, duplication and freeing of the security record attached to a filesystem context. (2) A hook to snoop source specifications. There may be multiple

[PATCH 08/34] vfs: Add LSM hooks for the new mount API [ver #12]

Add LSM hooks for use by the new mount API and filesystem context code. This includes: (1) Hooks to handle allocation, duplication and freeing of the security record attached to a filesystem context. (2) A hook to snoop source specifications. There may be multiple

Re: [PATCH 08/33] vfs: Add LSM hooks for the new mount API [ver #11]

James Morris wrote: > > (2) A hook to snoop source specifications. > > > What are source specifications? "/dev/sda1" or "my.nfs.server:/foo/bar". Actually, this hook is now gone. Source specification is done by way of a parameter with key of "source" and this can be specified multiple

Re: [PATCH 08/33] vfs: Add LSM hooks for the new mount API [ver #11]

James Morris wrote: > > (2) A hook to snoop source specifications. > > > What are source specifications? "/dev/sda1" or "my.nfs.server:/foo/bar". Actually, this hook is now gone. Source specification is done by way of a parameter with key of "source" and this can be specified multiple

Re: [PATCH 08/33] vfs: Add LSM hooks for the new mount API [ver #11]

On Wed, 1 Aug 2018, David Howells wrote: > (2) A hook to snoop source specifications. What are source specifications? -- James Morris

Re: [PATCH 08/33] vfs: Add LSM hooks for the new mount API [ver #11]

On Wed, 1 Aug 2018, David Howells wrote: > (2) A hook to snoop source specifications. What are source specifications? -- James Morris

[PATCH 08/33] vfs: Add LSM hooks for the new mount API [ver #11]

Add LSM hooks for use by the new mount API and filesystem context code. This includes: (1) Hooks to handle allocation, duplication and freeing of the security record attached to a filesystem context. (2) A hook to snoop source specifications. There may be multiple

[PATCH 08/33] vfs: Add LSM hooks for the new mount API [ver #11]

Add LSM hooks for use by the new mount API and filesystem context code. This includes: (1) Hooks to handle allocation, duplication and freeing of the security record attached to a filesystem context. (2) A hook to snoop source specifications. There may be multiple

[PATCH 08/38] vfs: Add LSM hooks for the new mount API [ver #10]

Add LSM hooks for use by the new mount API and filesystem context code. This includes: (1) Hooks to handle allocation, duplication and freeing of the security record attached to a filesystem context. (2) A hook to snoop source specifications. There may be multiple

[PATCH 08/38] vfs: Add LSM hooks for the new mount API [ver #10]

Add LSM hooks for use by the new mount API and filesystem context code. This includes: (1) Hooks to handle allocation, duplication and freeing of the security record attached to a filesystem context. (2) A hook to snoop source specifications. There may be multiple

[PATCH 06/32] vfs: Add LSM hooks for the new mount API [ver #9]

Add LSM hooks for use by the new mount API and filesystem context code. This includes: (1) Hooks to handle allocation, duplication and freeing of the security record attached to a filesystem context. (2) A hook to snoop source specifications. There may be multiple

[PATCH 06/32] vfs: Add LSM hooks for the new mount API [ver #9]

Add LSM hooks for use by the new mount API and filesystem context code. This includes: (1) Hooks to handle allocation, duplication and freeing of the security record attached to a filesystem context. (2) A hook to snoop source specifications. There may be multiple

[PATCH 07/32] selinux: Implement the new mount API LSM hooks [ver #9]

Implement the new mount API LSM hooks for SELinux. At some point the old hooks will need to be removed. Question: Should the ->fs_context_parse_source() hook be implemented to check the labels on any source devices specified? Signed-off-by: David Howells cc: Paul Moore cc: Stephen Smalley

[PATCH 07/32] selinux: Implement the new mount API LSM hooks [ver #9]

Implement the new mount API LSM hooks for SELinux. At some point the old hooks will need to be removed. Question: Should the ->fs_context_parse_source() hook be implemented to check the labels on any source devices specified? Signed-off-by: David Howells cc: Paul Moore cc: Stephen Smalley

[PATCH 05/32] selinux: Implement the new mount API LSM hooks [ver #8]

Implement the new mount API LSM hooks for SELinux. At some point the old hooks will need to be removed. Question: Should the ->fs_context_parse_source() hook be implemented to check the labels on any source devices specified? Signed-off-by: David Howells <dhowe...@redhat.com> cc: Paul

[PATCH 05/32] selinux: Implement the new mount API LSM hooks [ver #8]

Implement the new mount API LSM hooks for SELinux. At some point the old hooks will need to be removed. Question: Should the ->fs_context_parse_source() hook be implemented to check the labels on any source devices specified? Signed-off-by: David Howells cc: Paul Moore cc: Stephen Smalley

[PATCH 04/32] VFS: Add LSM hooks for the new mount API [ver #8]

Add LSM hooks for use by the new mount API and filesystem context code. This includes: (1) Hooks to handle allocation, duplication and freeing of the security record attached to a filesystem context. (2) A hook to snoop source specifications. There may be multiple

[PATCH 04/32] VFS: Add LSM hooks for the new mount API [ver #8]

Add LSM hooks for use by the new mount API and filesystem context code. This includes: (1) Hooks to handle allocation, duplication and freeing of the security record attached to a filesystem context. (2) A hook to snoop source specifications. There may be multiple

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 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, parse security

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

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, parse security options, etc. > Is there a reason not

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

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, parse security options, etc. > Is there a reason not apply a may_mount()

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

to include "selinux" somewhere in the subject line >> when the patch is predominately SELinux related (much like you did for >> the other LSMs in this patchset). > > I should probably evict the SELinux bits into their own patch since the point > of this patch is the LSM hooks,

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

ewhere in the subject line >> when the patch is predominately SELinux related (much like you did for >> the other LSMs in this patchset). > > I should probably evict the SELinux bits into their own patch since the point > of this patch is the LSM hooks, not specifically SELinux's im

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

tch is predominately SELinux related (much like you did for > the other LSMs in this patchset). I should probably evict the SELinux bits into their own patch since the point of this patch is the LSM hooks, not specifically SELinux's implementation thereof. > I can't say I've digested all of

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

related (much like you did for > the other LSMs in this patchset). I should probably evict the SELinux bits into their own patch since the point of this patch is the LSM hooks, not specifically SELinux's implementation thereof. > I can't say I've digested all of this yet, but what SEL

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

On Thu, Apr 19, 2018 at 9:31 AM, David Howells <dhowe...@redhat.com> wrote: > Add LSM hooks for use by the filesystem context code. This includes: > > (1) Hooks to handle allocation, duplication and freeing of the security > record attached to a filesystem context. > &

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

On Thu, Apr 19, 2018 at 9:31 AM, David Howells wrote: > Add LSM hooks for use by the filesystem context code. This includes: > > (1) Hooks to handle allocation, duplication and freeing of the security > record attached to a filesystem context. > > (2) A hook to sno

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

Add LSM hooks for use by the filesystem context code. This includes: (1) Hooks to handle allocation, duplication and freeing of the security record attached to a filesystem context. (2) A hook to snoop a mount options in key[=val] form. If the LSM decides it wants to handle

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

Add LSM hooks for use by the filesystem context code. This includes: (1) Hooks to handle allocation, duplication and freeing of the security record attached to a filesystem context. (2) A hook to snoop a mount options in key[=val] form. If the LSM decides it wants to handle

Re: [PATCH v4 1/3] security: Refactor LSM hooks into an array and enum

On Wed, Mar 7, 2018 at 12:23 PM, Casey Schaufler wrote: > On 3/7/2018 11:18 AM, Sargun Dhillon wrote: >> On Wed, Mar 7, 2018 at 9:45 AM, Casey Schaufler >> wrote: >>> On 3/6/2018 11:23 PM, Sargun Dhillon wrote: This commit should have no

Re: [PATCH v4 1/3] security: Refactor LSM hooks into an array and enum

On Wed, Mar 7, 2018 at 12:23 PM, Casey Schaufler wrote: > On 3/7/2018 11:18 AM, Sargun Dhillon wrote: >> On Wed, Mar 7, 2018 at 9:45 AM, Casey Schaufler >> wrote: >>> On 3/6/2018 11:23 PM, Sargun Dhillon wrote: This commit should have no functional change. It changes the security hook

Re: [PATCH v4 2/3] security: Expose a mechanism to load lsm hooks dynamically at runtime

On Wed, Mar 7, 2018 at 9:59 AM, Casey Schaufler wrote: > On 3/6/2018 11:23 PM, Sargun Dhillon wrote: >> This patch adds dynamic security hooks. These hooks are designed to allow >> for safe runtime loading. >> >> These hooks are only run after all built-in, and major LSMs

Re: [PATCH v4 2/3] security: Expose a mechanism to load lsm hooks dynamically at runtime

On Wed, Mar 7, 2018 at 9:59 AM, Casey Schaufler wrote: > On 3/6/2018 11:23 PM, Sargun Dhillon wrote: >> This patch adds dynamic security hooks. These hooks are designed to allow >> for safe runtime loading. >> >> These hooks are only run after all built-in, and major LSMs are run. >> The LSMs

Re: [PATCH v4 1/3] security: Refactor LSM hooks into an array and enum

On 3/7/2018 11:18 AM, Sargun Dhillon wrote: > On Wed, Mar 7, 2018 at 9:45 AM, Casey Schaufler > wrote: >> On 3/6/2018 11:23 PM, Sargun Dhillon wrote: >>> This commit should have no functional change. It changes the security hook >>> list heads struct into an array.

Re: [PATCH v4 1/3] security: Refactor LSM hooks into an array and enum

On 3/7/2018 11:18 AM, Sargun Dhillon wrote: > On Wed, Mar 7, 2018 at 9:45 AM, Casey Schaufler > wrote: >> On 3/6/2018 11:23 PM, Sargun Dhillon wrote: >>> This commit should have no functional change. It changes the security hook >>> list heads struct into an array. Additionally, it exposes all

Re: [PATCH v4 1/3] security: Refactor LSM hooks into an array and enum

On Wed, Mar 7, 2018 at 9:45 AM, Casey Schaufler wrote: > On 3/6/2018 11:23 PM, Sargun Dhillon wrote: >> This commit should have no functional change. It changes the security hook >> list heads struct into an array. Additionally, it exposes all of the hooks >> via an enum.

Re: [PATCH v4 1/3] security: Refactor LSM hooks into an array and enum

On Wed, Mar 7, 2018 at 9:45 AM, Casey Schaufler wrote: > On 3/6/2018 11:23 PM, Sargun Dhillon wrote: >> This commit should have no functional change. It changes the security hook >> list heads struct into an array. Additionally, it exposes all of the hooks >> via an enum. This loses memory layout

Re: [PATCH v4 2/3] security: Expose a mechanism to load lsm hooks dynamically at runtime

On 3/6/2018 11:23 PM, Sargun Dhillon wrote: > This patch adds dynamic security hooks. These hooks are designed to allow > for safe runtime loading. > > These hooks are only run after all built-in, and major LSMs are run. > The LSMs enabled by this feature must be minor LSMs, but they can poke > at

Re: [PATCH v4 2/3] security: Expose a mechanism to load lsm hooks dynamically at runtime

On 3/6/2018 11:23 PM, Sargun Dhillon wrote: > This patch adds dynamic security hooks. These hooks are designed to allow > for safe runtime loading. > > These hooks are only run after all built-in, and major LSMs are run. > The LSMs enabled by this feature must be minor LSMs, but they can poke > at

Re: [PATCH v4 1/3] security: Refactor LSM hooks into an array and enum

On 3/6/2018 11:23 PM, Sargun Dhillon wrote: > This commit should have no functional change. It changes the security hook > list heads struct into an array. Additionally, it exposes all of the hooks > via an enum. This loses memory layout randomization as the enum is not > randomized. Please

Re: [PATCH v4 1/3] security: Refactor LSM hooks into an array and enum

On 3/6/2018 11:23 PM, Sargun Dhillon wrote: > This commit should have no functional change. It changes the security hook > list heads struct into an array. Additionally, it exposes all of the hooks > via an enum. This loses memory layout randomization as the enum is not > randomized. Please

Re: [PATCH v4 0/3] Safe, dynamically loadable LSM hooks

removed > * xfrm singleton hook removed > > > Sargun Dhillon (3): > security: Refactor LSM hooks into an array and enum > security: Expose a mechanism to load lsm hooks dynamically at runtime > security: Add an example sample dynamic LSM > > include/linux/lsm

Re: [PATCH v4 0/3] Safe, dynamically loadable LSM hooks

removed > * xfrm singleton hook removed > > > Sargun Dhillon (3): > security: Refactor LSM hooks into an array and enum > security: Expose a mechanism to load lsm hooks dynamically at runtime > security: Add an example sample dynamic LSM > > include/linux/lsm

[PATCH v4 2/3] security: Expose a mechanism to load lsm hooks dynamically at runtime

This patch adds dynamic security hooks. These hooks are designed to allow for safe runtime loading. These hooks are only run after all built-in, and major LSMs are run. The LSMs enabled by this feature must be minor LSMs, but they can poke at the security blobs, as the blobs should be initialized

[PATCH v4 0/3] Safe, dynamically loadable LSM hooks

l is fixed * inode get/set security is removed * xfrm singleton hook removed Sargun Dhillon (3): security: Refactor LSM hooks into an array and enum security: Expose a mechanism to load lsm hooks dynamically at runtime security: Add an example sample dynamic LSM include/linux/lsm_hoo

[PATCH v4 2/3] security: Expose a mechanism to load lsm hooks dynamically at runtime

This patch adds dynamic security hooks. These hooks are designed to allow for safe runtime loading. These hooks are only run after all built-in, and major LSMs are run. The LSMs enabled by this feature must be minor LSMs, but they can poke at the security blobs, as the blobs should be initialized

[PATCH v4 0/3] Safe, dynamically loadable LSM hooks

l is fixed * inode get/set security is removed * xfrm singleton hook removed Sargun Dhillon (3): security: Refactor LSM hooks into an array and enum security: Expose a mechanism to load lsm hooks dynamically at runtime security: Add an example sample dynamic LSM include/linux/lsm_hoo

[PATCH v4 1/3] security: Refactor LSM hooks into an array and enum

This commit should have no functional change. It changes the security hook list heads struct into an array. Additionally, it exposes all of the hooks via an enum. This loses memory layout randomization as the enum is not randomized. Signed-off-by: Sargun Dhillon ---

[PATCH v4 1/3] security: Refactor LSM hooks into an array and enum

This commit should have no functional change. It changes the security hook list heads struct into an array. Additionally, it exposes all of the hooks via an enum. This loses memory layout randomization as the enum is not randomized. Signed-off-by: Sargun Dhillon --- include/linux/lsm_hooks.h |

[RFC PATCH v3 2/3] security: Expose a mechanism to load lsm hooks dynamically at runtime

This patch adds dynamic security hooks. These hooks are designed to allow for safe runtime loading. These hooks are only run after all built-in, and major LSMs are run. The LSMs enabled by this feature must be minor LSMs, but they can poke at the security blobs, as the blobs should be initialized

[RFC PATCH v3 2/3] security: Expose a mechanism to load lsm hooks dynamically at runtime

This patch adds dynamic security hooks. These hooks are designed to allow for safe runtime loading. These hooks are only run after all built-in, and major LSMs are run. The LSMs enabled by this feature must be minor LSMs, but they can poke at the security blobs, as the blobs should be initialized

[RFC PATCH v3 0/3] Safe, dynamically loadable LSM hooks

is removed * xfrm singleton hook removed Sargun Dhillon (3): security: Refactor LSM hooks into an array security: Expose a mechanism to load lsm hooks dynamically at runtime security: Add an example sample dynamic LSM include/linux/lsm_hoo

[RFC PATCH v3 1/3] security: Refactor LSM hooks into an array

This commit should have no functional change. It changes the security hook list heads struct into an array. Additionally, it exposes all of the hooks via an enum. This loses memory layout randomization as the enum is not randomized. Signed-off-by: Sargun Dhillon ---

[RFC PATCH v3 1/3] security: Refactor LSM hooks into an array

This commit should have no functional change. It changes the security hook list heads struct into an array. Additionally, it exposes all of the hooks via an enum. This loses memory layout randomization as the enum is not randomized. Signed-off-by: Sargun Dhillon --- include/linux/lsm_hooks.h |

[RFC PATCH v3 0/3] Safe, dynamically loadable LSM hooks

is removed * xfrm singleton hook removed Sargun Dhillon (3): security: Refactor LSM hooks into an array security: Expose a mechanism to load lsm hooks dynamically at runtime security: Add an example sample dynamic LSM include/linux/lsm_hoo

Re: [PATCH 02/14] VFS: Add LSM hooks for filesystem context [ver #6]

add cc: linux-security-mod...@vger.kernel.org On 10/06/17 08:49, David Howells wrote: > Add LSM hooks for use by the filesystem context code. This includes: > > (1) Hooks to handle allocation, duplication and freeing of the security > record attached to a filesystem conte

Re: [PATCH 02/14] VFS: Add LSM hooks for filesystem context [ver #6]

add cc: linux-security-mod...@vger.kernel.org On 10/06/17 08:49, David Howells wrote: > Add LSM hooks for use by the filesystem context code. This includes: > > (1) Hooks to handle allocation, duplication and freeing of the security > record attached to a filesystem conte

[PATCH 02/14] VFS: Add LSM hooks for filesystem context [ver #6]

Add LSM hooks for use by the filesystem context code. This includes: (1) Hooks to handle allocation, duplication and freeing of the security record attached to a filesystem context. (2) A hook to snoop a mount options in key[=val] form. If the LSM decides it wants to handle

  1   2   3   4   >