"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
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
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
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,
> > &
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.
Sig
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
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
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
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:
> > >
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
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 building the new
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
>
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
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
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
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.
Signed
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
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
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 | 81
kernel/bpf/verifier.c| 16 +---
kernel/trace/bpf_trace.c | 7 +++-
4 files change
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
Good 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 bo
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, or
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.
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
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
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 and
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.
>
&
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(-)
>
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
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
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 and
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
ng 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
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
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
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 these
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 these
erefore the pair of { vma->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 ev
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
d), LSM modules would be able 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
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
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 of these
if the
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 tim
On Wed, 1 Aug 2018, David Howells wrote:
> (2) A hook to snoop source specifications.
What are source specifications?
--
James Morris
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 of these
if the
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 of these
if the
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 of these
if the
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
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
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 of these
if the
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 options,
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() or
re 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'
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, bu
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 snoop
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 it, it
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
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 enab
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 of
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
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
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 explai
node 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
>
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
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
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 | 4
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
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 | 4
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
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 context.
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 it, it
On Sun, Aug 27, 2017 at 03:31:35PM +0200, Mickaël Salaün wrote:
>
> > How can you add 3rd argument? All FS events would have to get it,
> > but in some LSM hooks such argument will be meaningless, whereas
> > in other places it will carry useful info that rule can operate on
le) and numbers. Actually,
these four events have the same arg1 field (file handle) and the same
arg2 eBPF type (scalar), even if arg2 does not have the same semantic
(i.e. abstract FS action, IOCTL command…).
For example, if we want to extend the FS_FCNTL's context in the future,
w
a hard limit at all. Actually, the FS_FNCTL event should have
> three arguments (I'll add them in the next series): FS handle, FCNTL
> command and FCNTL argument. I made sure that it's really easy to add
> more arguments to the context of an event.
The reason I'm asking, because
On 24/08/2017 04:50, Alexei Starovoitov wrote:
> On Mon, Aug 21, 2017 at 02:09:28AM +0200, Mickaël Salaün wrote:
>> Handle 33 filesystem-related LSM hooks for the Landlock filesystem
>> event: LANDLOCK_SUBTYPE_EVENT_FS.
>>
>> A Landlock event wrap LSM hooks for simil
On Mon, Aug 21, 2017 at 02:09:28AM +0200, Mickaël Salaün wrote:
> Handle 33 filesystem-related LSM hooks for the Landlock filesystem
> event: LANDLOCK_SUBTYPE_EVENT_FS.
>
> A Landlock event wrap LSM hooks for similar kernel object types (e.g.
> struct file, struct path...). Multipl
On 21/08/2017 02:09, Mickaël Salaün wrote:
> Handle 33 filesystem-related LSM hooks for the Landlock filesystem
> event: LANDLOCK_SUBTYPE_EVENT_FS.
>
> A Landlock event wrap LSM hooks for similar kernel object types (e.g.
> struct file, struct path...). Multiple LSM hooks can t
Handle 33 filesystem-related LSM hooks for the Landlock filesystem
event: LANDLOCK_SUBTYPE_EVENT_FS.
A Landlock event wrap LSM hooks for similar kernel object types (e.g.
struct file, struct path...). Multiple LSM hooks can trigger the same
Landlock event.
Landlock handle nine coarse-grained
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 it, it
Add LSM hooks for use by the superblock configuration context code.
Signed-off-by: David Howells
---
include/linux/lsm_hooks.h | 39 ++
include/linux/security.h | 28 +++
security/security.c | 25 +++
security/selinux/hooks.c | 169
On Wed, Apr 19, 2017 at 3:03 PM, Mickaël Salaün wrote:
>
> On 19/04/2017 01:40, Kees Cook wrote:
>> On Tue, Apr 18, 2017 at 4:16 PM, Casey Schaufler
>> wrote:
>>> On 4/18/2017 3:44 PM, Mickaël Salaün wrote:
On 19/04/2017 00:17, Kees Cook wrote:
> On Tue, Mar 28, 2017 at 4:46 PM, Mickaël
On 4/19/2017 3:03 PM, Mickaël Salaün wrote:
> On 19/04/2017 01:40, Kees Cook wrote:
>> On Tue, Apr 18, 2017 at 4:16 PM, Casey Schaufler
>> wrote:
>>> On 4/18/2017 3:44 PM, Mickaël Salaün wrote:
On 19/04/2017 00:17, Kees Cook wrote:
> On Tue, Mar 28, 2017 at 4:46 PM, Mickaël Salaün wrote
On 19/04/2017 01:40, Kees Cook wrote:
> On Tue, Apr 18, 2017 at 4:16 PM, Casey Schaufler
> wrote:
>> On 4/18/2017 3:44 PM, Mickaël Salaün wrote:
>>> On 19/04/2017 00:17, Kees Cook wrote:
On Tue, Mar 28, 2017 at 4:46 PM, Mickaël Salaün wrote:
> +void __init landlock_add_hooks(void)
On Tue, Apr 18, 2017 at 4:16 PM, Casey Schaufler wrote:
> On 4/18/2017 3:44 PM, Mickaël Salaün wrote:
>> On 19/04/2017 00:17, Kees Cook wrote:
>>> On Tue, Mar 28, 2017 at 4:46 PM, Mickaël Salaün wrote:
+void __init landlock_add_hooks(void)
+{
+ pr_info("landlock: Version %u",
On Tue, Apr 18, 2017 at 3:44 PM, Mickaël Salaün wrote:
>
> On 19/04/2017 00:17, Kees Cook wrote:
>> On Tue, Mar 28, 2017 at 4:46 PM, Mickaël Salaün wrote:
>>> Handle 33 filesystem-related LSM hooks for the Landlock filesystem
>>> event: LANDLOCK_SUBTYPE_EVENT_FS.
On 4/18/2017 3:44 PM, Mickaël Salaün wrote:
> On 19/04/2017 00:17, Kees Cook wrote:
>> On Tue, Mar 28, 2017 at 4:46 PM, Mickaël Salaün wrote:
>>> Handle 33 filesystem-related LSM hooks for the Landlock filesystem
>>> event: LANDLOCK_SUBTYPE_EVENT_FS.
>>>
>
On 19/04/2017 00:17, Kees Cook wrote:
> On Tue, Mar 28, 2017 at 4:46 PM, Mickaël Salaün wrote:
>> Handle 33 filesystem-related LSM hooks for the Landlock filesystem
>> event: LANDLOCK_SUBTYPE_EVENT_FS.
>>
>> A Landlock event wrap LSM hooks for similar kernel object
On Tue, Mar 28, 2017 at 4:46 PM, Mickaël Salaün wrote:
> Handle 33 filesystem-related LSM hooks for the Landlock filesystem
> event: LANDLOCK_SUBTYPE_EVENT_FS.
>
> A Landlock event wrap LSM hooks for similar kernel object types (e.g.
> struct file, struct path...). Multiple LSM ho
Hi Mickaël,
[auto build test ERROR on net-next/master]
url:
https://github.com/0day-ci/linux/commits/Micka-l-Sala-n/Landlock-LSM-Toward-unprivileged-sandboxing/20170329-211258
config: i386-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
#
Handle 33 filesystem-related LSM hooks for the Landlock filesystem
event: LANDLOCK_SUBTYPE_EVENT_FS.
A Landlock event wrap LSM hooks for similar kernel object types (e.g.
struct file, struct path...). Multiple LSM hooks can trigger the same
Landlock event.
Landlock handle nine coarse-grained
Handle 33 filesystem-related LSM hooks for the Landlock filesystem
event: LANDLOCK_SUBTYPE_EVENT_FS.
A Landlock event wrap LSM hooks for similar kernel object types (e.g.
struct file, struct path...). Multiple LSM hooks can trigger the same
Landlock event.
Landlock handle nine coarse-grained
/linux/bpf.h
index 335616ab63ff..b6b531a868c0 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -563,8 +563,16 @@ struct xdp_md {
/* LSM hooks */
enum landlock_hook {
LANDLOCK_HOOK_UNSPEC,
+ LANDLOCK_HOOK_FILE_OPEN,
+ LANDLOCK_HOOK_FILE_PERMISSION
On 19/10/2016 17:19, Thomas Graf wrote:
> On 09/14/16 at 09:23am, Mickaël Salaün wrote:
>> diff --git a/include/linux/bpf.h b/include/linux/bpf.h
>> index 9aa01d9d3d80..36c3e482239c 100644
>> --- a/include/linux/bpf.h
>> +++ b/include/linux/bpf.h
>> @@ -85,6 +85,8 @@ enum bpf_arg_type {
>>
>>
On 09/14/16 at 09:23am, Mickaël Salaün wrote:
> diff --git a/include/linux/bpf.h b/include/linux/bpf.h
> index 9aa01d9d3d80..36c3e482239c 100644
> --- a/include/linux/bpf.h
> +++ b/include/linux/bpf.h
> @@ -85,6 +85,8 @@ enum bpf_arg_type {
>
> ARG_PTR_TO_CTX, /* pointer to context
Add LSM hooks which can be used by userland through Landlock (eBPF)
programs. This programs are limited to a whitelist of functions (cf.
next commit). The eBPF program context is depicted by the struct
landlock_data (cf. include/uapi/linux/bpf.h):
* hook: LSM hook ID
* origin: what triggered this
On 30/08/2016 22:18, Andy Lutomirski wrote:
> On Tue, Aug 30, 2016 at 1:10 PM, Mickaël Salaün wrote:
>>
>> On 30/08/2016 20:56, Andy Lutomirski wrote:
>>> On Aug 25, 2016 12:34 PM, "Mickaël Salaün" wrote:
>>>>
>>>> Add LSM
On Tue, Aug 30, 2016 at 1:10 PM, Mickaël Salaün wrote:
>
> On 30/08/2016 20:56, Andy Lutomirski wrote:
>> On Aug 25, 2016 12:34 PM, "Mickaël Salaün" wrote:
>>>
>>> Add LSM hooks which can be used by userland through Landlock (eBPF)
>>> prog
On 30/08/2016 20:56, Andy Lutomirski wrote:
> On Aug 25, 2016 12:34 PM, "Mickaël Salaün" wrote:
>>
>> Add LSM hooks which can be used by userland through Landlock (eBPF)
>> programs. This programs are limited to a whitelist of functions (cf.
>> next commit).
On Aug 25, 2016 12:34 PM, "Mickaël Salaün" wrote:
>
> Add LSM hooks which can be used by userland through Landlock (eBPF)
> programs. This programs are limited to a whitelist of functions (cf.
> next commit). The eBPF program context is depicted by the struct
> landlo
Add LSM hooks which can be used by userland through Landlock (eBPF)
programs. This programs are limited to a whitelist of functions (cf.
next commit). The eBPF program context is depicted by the struct
landlock_data (cf. include/uapi/linux/bpf.h):
* hook: LSM hook ID (useful when using the same
1 - 100 of 199 matches
Mail list logo
