Re: [RFC v3 07/22] landlock: Handle file comparisons
From: Jann Horn <hidden>
Date: 2016-09-14 19:07:31
Also in:
cgroups, lkml, netdev
On Wed, Sep 14, 2016 at 09:24:00AM +0200, Mickaël Salaün wrote:
Add eBPF functions to compare file system access with a Landlock file system handle: * bpf_landlock_cmp_fs_prop_with_struct_file(prop, map, map_op, file) This function allows to compare the dentry, inode, device or mount point of the currently accessed file, with a reference handle. * bpf_landlock_cmp_fs_beneath_with_struct_file(opt, map, map_op, file) This function allows an eBPF program to check if the current accessed file is the same or in the hierarchy of a reference handle.
[...]
quoted hunk ↗ jump to hunk
diff --git a/kernel/bpf/arraymap.c b/kernel/bpf/arraymap.c index 94256597eacd..edaab4c87292 100644 --- a/kernel/bpf/arraymap.c +++ b/kernel/bpf/arraymap.c@@ -603,6 +605,9 @@ static void landlock_put_handle(struct map_landlock_handle *handle) enum bpf_map_handle_type handle_type = handle->type; switch (handle_type) { + case BPF_MAP_HANDLE_TYPE_LANDLOCK_FS_FD: + path_put(&handle->path); + break; case BPF_MAP_HANDLE_TYPE_UNSPEC: default: WARN_ON(1);
[...]
quoted hunk ↗ jump to hunk
diff --git a/security/landlock/checker_fs.c b/security/landlock/checker_fs.c new file mode 100644 index 000000000000..39eb85dc7d18 --- /dev/null +++ b/security/landlock/checker_fs.c
[...]
+static inline u64 bpf_landlock_cmp_fs_prop_with_struct_file(u64 r1_property,
+ u64 r2_map, u64 r3_map_op, u64 r4_file, u64 r5)
+{
+ u8 property = (u8) r1_property;
+ struct bpf_map *map = (struct bpf_map *) (unsigned long) r2_map;
+ enum bpf_map_array_op map_op = r3_map_op;
+ struct file *file = (struct file *) (unsigned long) r4_file;
+ struct bpf_array *array = container_of(map, struct bpf_array, map);
+ struct path *p1, *p2;
+ struct map_landlock_handle *handle;
+ int i;Please don't use int when iterating over an array, use size_t.
+ /* for now, only handle OP_OR */
Is "OP_OR" an appropriate name for something that ANDs the success of checks? [...]
+ synchronize_rcu();
Can you put a comment here that explains what's going on?
+ for (i = 0; i < array->n_entries; i++) {
+ bool result_dentry = !(property & LANDLOCK_FLAG_FS_DENTRY);
+ bool result_inode = !(property & LANDLOCK_FLAG_FS_INODE);
+ bool result_device = !(property & LANDLOCK_FLAG_FS_DEVICE);
+ bool result_mount = !(property & LANDLOCK_FLAG_FS_MOUNT);
+
+ handle = (struct map_landlock_handle *)
+ (array->value + array->elem_size * i);
+
+ if (handle->type != BPF_MAP_HANDLE_TYPE_LANDLOCK_FS_FD) {
+ WARN_ON(1);
+ return -EFAULT;
+ }
+ p1 = &handle->path;
+
+ if (!result_dentry && p1->dentry == p2->dentry)
+ result_dentry = true;Why is this safe? As far as I can tell, this is not in an RCU read-side critical section (synchronize_rcu() was just called), and no lock has been taken. What prevents someone from removing the arraymap entry while we're looking at it? Am I missing something? [...]
+static inline u64 bpf_landlock_cmp_fs_beneath_with_struct_file(u64 r1_option,
+ u64 r2_map, u64 r3_map_op, u64 r4_file, u64 r5)
+{
+ u8 option = (u8) r1_option;
+ struct bpf_map *map = (struct bpf_map *) (unsigned long) r2_map;
+ enum bpf_map_array_op map_op = r3_map_op;
+ struct file *file = (struct file *) (unsigned long) r4_file;
+ struct bpf_array *array = container_of(map, struct bpf_array, map);
+ struct path *p1, *p2;
+ struct map_landlock_handle *handle;
+ int i;As above, please use size_t.
Attachments
- signature.asc [application/pgp-signature] 819 bytes