* [PATCH 03/11] security: Add a hook for the point of notification insertion [ver #8]
From: David Howells @ 2019-09-04 22:16 UTC (permalink / raw)
To: keyrings, linux-usb, linux-block
Cc: dhowells, torvalds, Casey Schaufler, Stephen Smalley,
Greg Kroah-Hartman, nicolas.dichtel, raven, Christian Brauner,
dhowells, linux-security-module, linux-fsdevel, linux-api,
linux-security-module, linux-kernel
In-Reply-To: <156763534546.18676.3530557439501101639.stgit@warthog.procyon.org.uk>
Add a security hook that allows an LSM to rule on whether a notification
message is allowed to be inserted into a particular watch queue.
The hook is given the following information:
(1) The credentials of the triggerer (which may be init_cred for a system
notification, eg. a hardware error).
(2) The credentials of the whoever set the watch.
(3) The notification message.
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Casey Schaufler <casey@schaufler-ca.com>
cc: Stephen Smalley <sds@tycho.nsa.gov>
cc: linux-security-module@vger.kernel.org
---
include/linux/lsm_hooks.h | 14 ++++++++++++++
include/linux/security.h | 15 ++++++++++++++-
security/security.c | 9 +++++++++
3 files changed, 37 insertions(+), 1 deletion(-)
diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index b0cdefcda4e6..257d803dcf6f 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -1424,6 +1424,12 @@
* Check to see if a process is allowed to watch for event notifications
* from devices (as a global set).
*
+ * @post_notification:
+ * Check to see if a watch notification can be posted to a particular
+ * queue.
+ * @w_cred: The credentials of the whoever set the watch.
+ * @cred: The event-triggerer's credentials
+ * @n: The notification being posted
*
* Security hooks for using the eBPF maps and programs functionalities through
* eBPF syscalls.
@@ -1706,6 +1712,11 @@ union security_list_options {
#ifdef CONFIG_DEVICE_NOTIFICATIONS
int (*watch_devices)(void);
#endif
+#ifdef CONFIG_WATCH_QUEUE
+ int (*post_notification)(const struct cred *w_cred,
+ const struct cred *cred,
+ struct watch_notification *n);
+#endif
#ifdef CONFIG_SECURITY_NETWORK
int (*unix_stream_connect)(struct sock *sock, struct sock *other,
@@ -1988,6 +1999,9 @@ struct security_hook_heads {
#ifdef CONFIG_DEVICE_NOTIFICATIONS
struct hlist_head watch_devices;
#endif
+#ifdef CONFIG_WATCH_QUEUE
+ struct hlist_head post_notification;
+#endif /* CONFIG_WATCH_QUEUE */
#ifdef CONFIG_SECURITY_NETWORK
struct hlist_head unix_stream_connect;
struct hlist_head unix_may_send;
diff --git a/include/linux/security.h b/include/linux/security.h
index 3be44354d308..24c54b9ff0a1 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -57,6 +57,8 @@ struct mm_struct;
struct fs_context;
struct fs_parameter;
enum fs_value_type;
+struct watch;
+struct watch_notification;
/* Default (no) options for the capable function */
#define CAP_OPT_NONE 0x0
@@ -1222,6 +1224,18 @@ static inline int security_watch_devices(void)
return 0;
}
#endif
+#if defined(CONFIG_SECURITY) && defined(CONFIG_WATCH_QUEUE)
+int security_post_notification(const struct cred *w_cred,
+ const struct cred *cred,
+ struct watch_notification *n);
+#else
+static inline int security_post_notification(const struct cred *w_cred,
+ const struct cred *cred,
+ struct watch_notification *n)
+{
+ return 0;
+}
+#endif
#ifdef CONFIG_SECURITY_NETWORK
@@ -1847,4 +1861,3 @@ static inline void security_bpf_prog_free(struct bpf_prog_aux *aux)
#endif /* CONFIG_BPF_SYSCALL */
#endif /* ! __LINUX_SECURITY_H */
-
diff --git a/security/security.c b/security/security.c
index 007eb48bc848..b719c5a5b2ba 100644
--- a/security/security.c
+++ b/security/security.c
@@ -1916,6 +1916,15 @@ int security_inode_getsecctx(struct inode *inode, void **ctx, u32 *ctxlen)
}
EXPORT_SYMBOL(security_inode_getsecctx);
+#ifdef CONFIG_WATCH_QUEUE
+int security_post_notification(const struct cred *w_cred,
+ const struct cred *cred,
+ struct watch_notification *n)
+{
+ return call_int_hook(post_notification, 0, w_cred, cred, n);
+}
+#endif /* CONFIG_WATCH_QUEUE */
+
#ifdef CONFIG_KEY_NOTIFICATIONS
int security_watch_key(struct key *key)
{
^ permalink raw reply related
* [PATCH 02/11] security: Add hooks to rule on setting a watch [ver #8]
From: David Howells @ 2019-09-04 22:16 UTC (permalink / raw)
To: keyrings, linux-usb, linux-block
Cc: dhowells, torvalds, Casey Schaufler, Stephen Smalley,
Greg Kroah-Hartman, nicolas.dichtel, raven, Christian Brauner,
dhowells, linux-security-module, linux-fsdevel, linux-api,
linux-security-module, linux-kernel
In-Reply-To: <156763534546.18676.3530557439501101639.stgit@warthog.procyon.org.uk>
Add security hooks that will allow an LSM to rule on whether or not a watch
may be set. More than one hook is required as the watches watch different
types of object.
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Casey Schaufler <casey@schaufler-ca.com>
cc: Stephen Smalley <sds@tycho.nsa.gov>
cc: linux-security-module@vger.kernel.org
---
include/linux/lsm_hooks.h | 24 ++++++++++++++++++++++++
include/linux/security.h | 17 +++++++++++++++++
security/security.c | 14 ++++++++++++++
3 files changed, 55 insertions(+)
diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index df1318d85f7d..b0cdefcda4e6 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -1413,6 +1413,18 @@
* @ctx is a pointer in which to place the allocated security context.
* @ctxlen points to the place to put the length of @ctx.
*
+ * Security hooks for the general notification queue:
+ *
+ * @watch_key:
+ * Check to see if a process is allowed to watch for event notifications
+ * from a key or keyring.
+ * @key: The key to watch.
+ *
+ * @watch_devices:
+ * Check to see if a process is allowed to watch for event notifications
+ * from devices (as a global set).
+ *
+ *
* Security hooks for using the eBPF maps and programs functionalities through
* eBPF syscalls.
*
@@ -1688,6 +1700,12 @@ union security_list_options {
int (*inode_notifysecctx)(struct inode *inode, void *ctx, u32 ctxlen);
int (*inode_setsecctx)(struct dentry *dentry, void *ctx, u32 ctxlen);
int (*inode_getsecctx)(struct inode *inode, void **ctx, u32 *ctxlen);
+#ifdef CONFIG_KEY_NOTIFICATIONS
+ int (*watch_key)(struct key *key);
+#endif
+#ifdef CONFIG_DEVICE_NOTIFICATIONS
+ int (*watch_devices)(void);
+#endif
#ifdef CONFIG_SECURITY_NETWORK
int (*unix_stream_connect)(struct sock *sock, struct sock *other,
@@ -1964,6 +1982,12 @@ struct security_hook_heads {
struct hlist_head inode_notifysecctx;
struct hlist_head inode_setsecctx;
struct hlist_head inode_getsecctx;
+#ifdef CONFIG_KEY_NOTIFICATIONS
+ struct hlist_head watch_key;
+#endif
+#ifdef CONFIG_DEVICE_NOTIFICATIONS
+ struct hlist_head watch_devices;
+#endif
#ifdef CONFIG_SECURITY_NETWORK
struct hlist_head unix_stream_connect;
struct hlist_head unix_may_send;
diff --git a/include/linux/security.h b/include/linux/security.h
index 5f7441abbf42..3be44354d308 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -1206,6 +1206,23 @@ static inline int security_inode_getsecctx(struct inode *inode, void **ctx, u32
}
#endif /* CONFIG_SECURITY */
+#if defined(CONFIG_SECURITY) && defined(CONFIG_KEY_NOTIFICATIONS)
+int security_watch_key(struct key *key);
+#else
+static inline int security_watch_key(struct key *key)
+{
+ return 0;
+}
+#endif
+#if defined(CONFIG_SECURITY) && defined(CONFIG_DEVICE_NOTIFICATIONS)
+int security_watch_devices(void);
+#else
+static inline int security_watch_devices(void)
+{
+ return 0;
+}
+#endif
+
#ifdef CONFIG_SECURITY_NETWORK
int security_unix_stream_connect(struct sock *sock, struct sock *other, struct sock *newsk);
diff --git a/security/security.c b/security/security.c
index 250ee2d76406..007eb48bc848 100644
--- a/security/security.c
+++ b/security/security.c
@@ -1916,6 +1916,20 @@ int security_inode_getsecctx(struct inode *inode, void **ctx, u32 *ctxlen)
}
EXPORT_SYMBOL(security_inode_getsecctx);
+#ifdef CONFIG_KEY_NOTIFICATIONS
+int security_watch_key(struct key *key)
+{
+ return call_int_hook(watch_key, 0, key);
+}
+#endif
+
+#ifdef CONFIG_DEVICE_NOTIFICATIONS
+int security_watch_devices(void)
+{
+ return call_int_hook(watch_devices, 0);
+}
+#endif
+
#ifdef CONFIG_SECURITY_NETWORK
int security_unix_stream_connect(struct sock *sock, struct sock *other, struct sock *newsk)
^ permalink raw reply related
* [PATCH 01/11] uapi: General notification ring definitions [ver #8]
From: David Howells @ 2019-09-04 22:15 UTC (permalink / raw)
To: keyrings, linux-usb, linux-block
Cc: dhowells, torvalds, Casey Schaufler, Stephen Smalley,
Greg Kroah-Hartman, nicolas.dichtel, raven, Christian Brauner,
dhowells, linux-security-module, linux-fsdevel, linux-api,
linux-security-module, linux-kernel
In-Reply-To: <156763534546.18676.3530557439501101639.stgit@warthog.procyon.org.uk>
Add UAPI definitions for the general notification ring, including the
following pieces:
(1) struct watch_notification.
This is the metadata header for each entry in the ring. It includes a
type and subtype that indicate the source of the message
(eg. WATCH_TYPE_MOUNT_NOTIFY) and the kind of the message
(eg. NOTIFY_MOUNT_NEW_MOUNT).
The header also contains an information field that conveys the
following information:
- WATCH_INFO_LENGTH. The size of the entry (entries are variable
length).
- WATCH_INFO_ID. The watch ID specified when the watchpoint was
set.
- WATCH_INFO_TYPE_INFO. (Sub)type-specific information.
- WATCH_INFO_FLAG_*. Flag bits overlain on the type-specific
information. For use by the type.
All the information in the header can be used in filtering messages at
the point of writing into the buffer.
(2) struct watch_queue_buffer.
This describes the layout of the ring. Note that the first slots in
the ring contain a special metadata entry that contains the ring
pointers. The producer in the kernel knows to skip this and it has a
proper header (WATCH_TYPE_META, WATCH_META_SKIP_NOTIFICATION) that
indicates the size so that the ring consumer can handle it the same as
any other record and just skip it.
Note that this means that ring entries can never be split over the end
of the ring, so if an entry would need to be split, a skip record is
inserted to wrap the ring first; this is also WATCH_TYPE_META,
WATCH_META_SKIP_NOTIFICATION.
(3) WATCH_INFO_NOTIFICATIONS_LOST.
This is a flag that can be set in the metadata header by the kernel to
indicate that at least one message was lost since it was last cleared
by userspace.
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
include/uapi/linux/watch_queue.h | 67 ++++++++++++++++++++++++++++++++++++++
1 file changed, 67 insertions(+)
create mode 100644 include/uapi/linux/watch_queue.h
diff --git a/include/uapi/linux/watch_queue.h b/include/uapi/linux/watch_queue.h
new file mode 100644
index 000000000000..70f575099968
--- /dev/null
+++ b/include/uapi/linux/watch_queue.h
@@ -0,0 +1,67 @@
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
+#ifndef _UAPI_LINUX_WATCH_QUEUE_H
+#define _UAPI_LINUX_WATCH_QUEUE_H
+
+#include <linux/types.h>
+
+enum watch_notification_type {
+ WATCH_TYPE_META = 0, /* Special record */
+ WATCH_TYPE___NR = 1
+};
+
+enum watch_meta_notification_subtype {
+ WATCH_META_SKIP_NOTIFICATION = 0, /* Just skip this record */
+ WATCH_META_REMOVAL_NOTIFICATION = 1, /* Watched object was removed */
+};
+
+#define WATCH_LENGTH_GRANULARITY sizeof(__u64)
+
+/*
+ * Notification record header. This is aligned to 64-bits so that subclasses
+ * can contain __u64 fields.
+ */
+struct watch_notification {
+ __u32 type:24; /* enum watch_notification_type */
+ __u32 subtype:8; /* Type-specific subtype (filterable) */
+ __u32 info;
+#define WATCH_INFO_LENGTH 0x0000003f /* Length of record / sizeof(watch_notification) */
+#define WATCH_INFO_LENGTH__SHIFT 0
+#define WATCH_INFO_ID 0x0000ff00 /* ID of watchpoint, if type-appropriate */
+#define WATCH_INFO_ID__SHIFT 8
+#define WATCH_INFO_TYPE_INFO 0xffff0000 /* Type-specific info */
+#define WATCH_INFO_TYPE_INFO__SHIFT 16
+#define WATCH_INFO_FLAG_0 0x00010000 /* Type-specific info, flag bit 0 */
+#define WATCH_INFO_FLAG_1 0x00020000 /* ... */
+#define WATCH_INFO_FLAG_2 0x00040000
+#define WATCH_INFO_FLAG_3 0x00080000
+#define WATCH_INFO_FLAG_4 0x00100000
+#define WATCH_INFO_FLAG_5 0x00200000
+#define WATCH_INFO_FLAG_6 0x00400000
+#define WATCH_INFO_FLAG_7 0x00800000
+} __attribute__((aligned(WATCH_LENGTH_GRANULARITY)));
+
+struct watch_queue_buffer {
+ union {
+ /* The first few entries are special, containing the
+ * ring management variables.
+ */
+ struct {
+ struct watch_notification watch; /* WATCH_TYPE_META */
+ __u32 head; /* Ring head index */
+ __u32 tail; /* Ring tail index */
+ __u32 mask; /* Ring index mask */
+ __u32 __reserved;
+ } meta;
+ struct watch_notification slots[0];
+ };
+};
+
+/*
+ * The Metadata pseudo-notification message uses a flag bits in the information
+ * field to convey the fact that messages have been lost. We can only use a
+ * single bit in this manner per word as some arches that support SMP
+ * (eg. parisc) have no kernel<->user atomic bit ops.
+ */
+#define WATCH_INFO_NOTIFICATIONS_LOST WATCH_INFO_FLAG_0
+
+#endif /* _UAPI_LINUX_WATCH_QUEUE_H */
^ permalink raw reply related
* [PATCH 00/11] Keyrings, Block and USB notifications [ver #8]
From: David Howells @ 2019-09-04 22:15 UTC (permalink / raw)
To: keyrings, linux-usb, linux-block
Cc: dhowells, torvalds, Casey Schaufler, Stephen Smalley,
Greg Kroah-Hartman, nicolas.dichtel, raven, Christian Brauner,
dhowells, linux-security-module, linux-fsdevel, linux-api,
linux-security-module, linux-kernel
Here's a set of patches to add a general notification queue concept and to
add event sources such as:
(1) Keys/keyrings, such as linking and unlinking keys and changing their
attributes.
(2) General device events (single common queue) including:
- Block layer events, such as device errors
- USB subsystem events, such as device attach/remove, device reset,
device errors.
I have patches for adding superblock and mount topology watches also,
though those are not in this set as there are other dependencies.
Tests for the key/keyring events can be found on the keyutils next branch:
https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/keyutils.git/log/?h=next
Notifications are done automatically inside of the testing infrastructure
on every change to that every test makes to a key or keyring.
Manual pages can be found there also, including pages for the
watch_queue(7) and watch_devices(2) system calls (these should be
transferred to the manpages package if taken upstream) and the
keyctl_watch_key(3) function.
LSM hooks are included:
(1) A set of hooks are provided that allow an LSM to rule on whether or
not a watch may be set. Each of these hooks takes a different
"watched object" parameter, so they're not really shareable. The LSM
should use current's credentials. [Wanted by SELinux & Smack]
(2) A hook is provided to allow an LSM to rule on whether or not a
particular message may be posted to a particular queue. This is given
the credentials from the event generator (which may be the system) and
the watch setter. [Wanted by Smack]
I've provided SELinux and Smack with implementations of some of these hooks.
Design decisions:
(1) A misc chardev is used to create and open a ring buffer:
fd = open("/dev/watch_queue", O_RDWR);
which is then configured and mmap'd into userspace:
ioctl(fd, IOC_WATCH_QUEUE_SET_SIZE, BUF_SIZE);
ioctl(fd, IOC_WATCH_QUEUE_SET_FILTER, &filter);
buf = mmap(NULL, BUF_SIZE * page_size, PROT_READ | PROT_WRITE,
MAP_SHARED, fd, 0);
The fd cannot be read or written and userspace just pulls data out of
the mapped buffer directly.
(2) The ring index pointers are exposed to userspace through the buffer.
Userspace should only update the tail pointer and never the head
pointer or risk breaking the buffer. The kernel checks that the
pointers appear valid before trying to use them.
(3) The ring pointers are held inside the ring itself at the front inside
a special 'skip' record. This means it's not necessary to allocate an
extra locked page just for them - which would be contributory to the
locked memory rlimit.
(3) poll() can be used to wait for data to appear in the buffer.
(4) Records in the buffer are binary, typed and have a length so that they
can be of varying size.
This allows multiple heterogeneous sources to share a common buffer;
there are 16 million types available, of which I've used just a few,
so there is scope for others to be used. Tags may be specified when a
watchpoint is created to help distinguish the sources.
(5) Records are filterable as types have up to 256 subtypes that can be
individually filtered. Other filtration is also available.
(6) Each time the buffer is opened, a new buffer is created - this means
that there's no interference between watchers.
(7) When recording a notification, the kernel will not sleep, but will
rather mark a queue as overrun if there's insufficient space, thereby
avoiding userspace causing the kernel to hang. This does require the
buffer to be locked into memory.
(8) The 'watchpoint' should be specific where possible, meaning that you
specify the object that you want to watch.
(9) The buffer is created and then watchpoints are attached to it, using
one of:
keyctl_watch_key(KEY_SPEC_SESSION_KEYRING, fd, 0x01);
watch_devices(fd, 0x02, 0);
where in both cases, fd indicates the queue and the number after is a
tag between 0 and 255.
(10) Watches are removed if either the watch buffer is destroyed or the
watched object is destroyed.
Things I want to avoid:
(1) Introducing features that make the core VFS dependent on the network
stack or networking namespaces (ie. usage of netlink).
(2) Dumping all this stuff into dmesg and having a daemon that sits there
parsing the output and distributing it as this then puts the
responsibility for security into userspace and makes handling
namespaces tricky. Further, dmesg might not exist or might be
inaccessible inside a container.
(3) Letting users see events they shouldn't be able to see.
The patches can be found here also:
http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=notifications-core
Changes:
ver #8:
(*) Added comments on the kernel-side memory barriers for the ring buffer.
(*) Reworked the filter check function to remove the hard-coded numbers.
(*) Removed the USB bus notifications for now as there was a bug in there
causing a crash.
(*) Added syscall hooks for arm64.
ver #7:
(*) Removed the 'watch' argument from the security_watch_key() and
security_watch_devices() hooks as current_cred() can be used instead
of watch->cred.
ver #6:
(*) Fix mmap bug in watch_queue driver.
(*) Add an extended removal notification that can transmit an identifier
to userspace (such as a key ID).
(*) Don't produce a instantiation notification in mark_key_instantiated()
but rather do it in the caller to prevent key updates from producing
an instantiate notification as well as an update notification.
(*) Set the right number of filters in the sample program.
(*) Provide preliminary hook implementations for SELinux and Smack.
ver #5:
(*) Split the superblock watch and mount watch parts out into their own
branch (notifications-mount) as they really need certain fsinfo()
attributes.
(*) Rearrange the watch notification UAPI header to push the length down
to bits 0-5 and remove the lost-message bits. The userspace's watch
ID tag is moved to bits 8-15 and then the message type is allocated
all of bits 16-31 for its own purposes.
The lost-message bit is moved over to the header, rather than being
placed in the next message to be generated and given its own word so
it can be cleared with xchg(,0) for parisc.
(*) The security_post_notification() hook is no longer called with the
spinlock held and softirqs disabled - though the RCU readlock is still
held.
(*) Buffer pages are now accounted towards RLIMIT_MEMLOCK and CAP_IPC_LOCK
will skip the overuse check.
(*) The buffer is marked VM_DONTEXPAND.
(*) Save the watch-setter's creds in struct watch and give that to the LSM
hook for posting a message.
ver #4:
(*) Split the basic UAPI bits out into their own patch and then split the
LSM hooks out into an intermediate patch. Add LSM hooks for setting
watches.
Rename the *_notify() system calls to watch_*() for consistency.
ver #3:
(*) I've added a USB notification source and reformulated the block
notification source so that there's now a common watch list, for which
the system call is now device_notify().
I've assigned a pair of unused ioctl numbers in the 'W' series to the
ioctls added by this series.
I've also added a description of the kernel API to the documentation.
ver #2:
(*) I've fixed various issues raised by Jann Horn and GregKH and moved to
krefs for refcounting. I've added some security features to try and
give Casey Schaufler the LSM control he wants.
David
---
David Howells (11):
uapi: General notification ring definitions
security: Add hooks to rule on setting a watch
security: Add a hook for the point of notification insertion
General notification queue with user mmap()'able ring buffer
keys: Add a notification facility
Add a general, global device notification watch list
block: Add block layer notifications
usb: Add USB subsystem notifications
Add sample notification program
selinux: Implement the watch_key security hook
smack: Implement the watch_key and post_notification hooks
Documentation/ioctl/ioctl-number.rst | 1
Documentation/security/keys/core.rst | 58 ++
Documentation/watch_queue.rst | 460 ++++++++++++++
arch/alpha/kernel/syscalls/syscall.tbl | 1
arch/arm/tools/syscall.tbl | 1
arch/arm64/include/asm/unistd.h | 2
arch/arm64/include/asm/unistd32.h | 2
arch/ia64/kernel/syscalls/syscall.tbl | 1
arch/m68k/kernel/syscalls/syscall.tbl | 1
arch/microblaze/kernel/syscalls/syscall.tbl | 1
arch/mips/kernel/syscalls/syscall_n32.tbl | 1
arch/mips/kernel/syscalls/syscall_n64.tbl | 1
arch/mips/kernel/syscalls/syscall_o32.tbl | 1
arch/parisc/kernel/syscalls/syscall.tbl | 1
arch/powerpc/kernel/syscalls/syscall.tbl | 1
arch/s390/kernel/syscalls/syscall.tbl | 1
arch/sh/kernel/syscalls/syscall.tbl | 1
arch/sparc/kernel/syscalls/syscall.tbl | 1
arch/x86/entry/syscalls/syscall_32.tbl | 1
arch/x86/entry/syscalls/syscall_64.tbl | 1
arch/xtensa/kernel/syscalls/syscall.tbl | 1
block/Kconfig | 9
block/blk-core.c | 29 +
drivers/base/Kconfig | 9
drivers/base/Makefile | 1
drivers/base/watch.c | 90 +++
drivers/misc/Kconfig | 13
drivers/misc/Makefile | 1
drivers/misc/watch_queue.c | 898 +++++++++++++++++++++++++++
drivers/usb/core/Kconfig | 9
drivers/usb/core/devio.c | 49 +
drivers/usb/core/hub.c | 4
include/linux/blkdev.h | 15
include/linux/device.h | 7
include/linux/key.h | 3
include/linux/lsm_audit.h | 1
include/linux/lsm_hooks.h | 38 +
include/linux/sched/user.h | 3
include/linux/security.h | 32 +
include/linux/syscalls.h | 1
include/linux/usb.h | 18 +
include/linux/watch_queue.h | 94 +++
include/uapi/asm-generic/unistd.h | 4
include/uapi/linux/keyctl.h | 2
include/uapi/linux/watch_queue.h | 181 +++++
kernel/sys_ni.c | 1
samples/Kconfig | 6
samples/Makefile | 1
samples/watch_queue/Makefile | 8
samples/watch_queue/watch_test.c | 231 +++++++
security/keys/Kconfig | 9
security/keys/compat.c | 3
security/keys/gc.c | 5
security/keys/internal.h | 30 +
security/keys/key.c | 38 +
security/keys/keyctl.c | 99 +++
security/keys/keyring.c | 20 -
security/keys/request_key.c | 4
security/security.c | 23 +
security/selinux/hooks.c | 14
security/smack/smack_lsm.c | 82 ++
61 files changed, 2592 insertions(+), 32 deletions(-)
create mode 100644 Documentation/watch_queue.rst
create mode 100644 drivers/base/watch.c
create mode 100644 drivers/misc/watch_queue.c
create mode 100644 include/linux/watch_queue.h
create mode 100644 include/uapi/linux/watch_queue.h
create mode 100644 samples/watch_queue/Makefile
create mode 100644 samples/watch_queue/watch_test.c
^ permalink raw reply
* Re: general protection fault in smack_socket_sendmsg
From: Casey Schaufler @ 2019-09-04 21:07 UTC (permalink / raw)
To: Tetsuo Handa, Hillf Danton, syzbot
Cc: jmorris, linux-kernel, linux-security-module, serge,
syzkaller-bugs
In-Reply-To: <b2a7cbb6-2243-d591-41e7-955e1e1e4785@I-love.SAKURA.ne.jp>
On 9/4/2019 3:16 AM, Tetsuo Handa wrote:
> On 2019/09/04 8:17, Casey Schaufler wrote:
>> On 8/30/2019 10:33 PM, Hillf Danton wrote:
>>>> dashboard link: https://syzkaller.appspot.com/bug?extid=5fd781d646d4fcbdfeb0
>> If you want to add a description and signed-off-by I will take this.
> Excuse me, but this bug was already closed as dup of "KASAN: use-after-free Read in rxrpc_send_keepalive".
I will hold off then. Thanks.
^ permalink raw reply
* Re: [PATCH] selinux: fix residual uses of current_security() for the SELinux blob
From: James Morris @ 2019-09-04 19:35 UTC (permalink / raw)
To: Stephen Smalley
Cc: paul, keescook, casey, selinux, linux-security-module, dhowells
In-Reply-To: <20190904143248.7003-1-sds@tycho.nsa.gov>
On Wed, 4 Sep 2019, Stephen Smalley wrote:
> We need to use selinux_cred() to fetch the SELinux cred blob instead
> of directly using current->security or current_security(). There
> were a couple of lingering uses of current_security() in the SELinux code
> that were apparently missed during the earlier conversions. IIUC, this
> would only manifest as a bug if multiple security modules including
> SELinux are enabled and SELinux is not first in the lsm order. After
> this change, there appear to be no other users of current_security()
> in-tree; perhaps we should remove it altogether.
>
> Fixes: bbd3662a8348 ("Infrastructure management of the cred security blob")
> Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Reviewed-by: James Morris <jamorris@linux.microsoft.com>
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: [PATCH v8 00/28] LSM: Module stacking for AppArmor
From: Casey Schaufler @ 2019-09-04 19:13 UTC (permalink / raw)
To: jmorris, linux-security-module, selinux
Cc: casey.schaufler, keescook, john.johansen, penguin-kernel, paul,
sds
In-Reply-To: <20190829232935.7099-1-casey@schaufler-ca.com>
On 8/29/2019 4:29 PM, Casey Schaufler wrote:
> This patchset provides the changes required for
> the AppArmor security module to stack safely with any other.
What more needs doing before we can land this airship?
The only outstanding issue I know about is the uses of
current_security() in SELinux, and Stephen has a patch
for that. I could see rebasing it, as security-next is
a little bit behind the times, but that's just merge work.
We could bikeshed the "compound" context format if we
have to, and argue about what capabilities are required
for /proc/self/attr/display if we must.
If there's objection to the number of patches (28 > 15)
there are reasonable ways to squash them. If there's objection
to the amount of change there are rational stages.
I'm heading off on holiday, and will be limiting my
screen time for the next couple weeks. Think about it.
Thank you.
>
> v8: Incorporate feedback from v7
> - Minor clean-up in display value management
> - refactor "compound" context creation to use a common
> append_ctx() function.
>
> v7: Incorporate feedback from v6
> - Make setting the display a privileged operation. The
> availability of compound contexts reduces the need for
> setting the display.
>
> v6: Incorporate feedback from v5
> - Add subj_<lsm>= and obj_<lsm>= fields to audit records
> - Add /proc/.../attr/context to get the full context in
> lsmname\0value\0... format as suggested by Simon McVittie
> - Add SO_PEERCONTEXT for getsockopt() to get the full context
> in the same format, also suggested by Simon McVittie.
> - Add /sys/kernel/security/lsm_display_default to provide
> the display default value.
>
> v5: Incorporate feedback from v4
> - Initialize the lsmcontext in security_secid_to_secctx()
> - Clear the lsmcontext in all security_release_secctx() cases
> - Don't use the "display" on strictly internal context
> interfaces.
> - The SELinux binder hooks check for cases where the context
> "display" isn't compatible with SELinux.
>
> v4: Incorporate feedback from v3
> - Mark new lsm_<blob>_alloc functions static
> - Replace the lsm and slot fields of the security_hook_list
> with a pointer to a LSM allocated lsm_id structure. The
> LSM identifies if it needs a slot explicitly. Use the
> lsm_id rather than make security_add_hooks return the
> slot value.
> - Validate slot values used in security.c
> - Reworked the "display" process attribute handling so that
> it works right and doesn't use goofy list processing.
> - fix display value check in dentry_init_security
> - Replace audit_log of secids with '?' instead of deleting
> the audit log
>
> v3: Incorporate feedback from v2
> - Make lsmblob parameter and variable names more
> meaningful, changing "le" and "l" to "blob".
> - Improve consistency of constant naming.
> - Do more sanity checking during LSM initialization.
> - Be a bit clearer about what is temporary scaffolding.
> - Rather than clutter security_getpeersec_dgram with
> otherwise unnecessary checks remove the apparmor
> stub, which does nothing useful.
>
> Patches 0001-0003 complete the process of moving management
> of security blobs that might be shared from the individual
> modules to the infrastructure.
>
> Patches 0004-0014 replace system use of a "secid" with
> a structure "lsmblob" containing information from the
> security modules to be held and reused later. At this
> point lsmblob contains an array of u32 secids, one "slot"
> for each of the security modules compiled into the
> kernel that used secids. A "slot" is allocated when
> a security module requests one.
> The infrastructure is changed to use the slot number
> to pass the correct secid to or from the security module
> hooks.
>
> It is important that the lsmblob be a fixed size entity
> that does not have to be allocated. Several of the places
> where it is used would have performance and/or locking
> issues with dynamic allocation.
>
> Patch 0015 provides a mechanism for a process to
> identify which security module's hooks should be used
> when displaying or converting a security context string.
> A new interface /proc/.../attr/display contains the name
> of the security module to show. Reading from this file
> will present the name of the module, while writing to
> it will set the value. Only names of active security
> modules are accepted. Internally, the name is translated
> to the appropriate "slot" number for the module which
> is then stored in the task security blob. Setting the
> display requires CAP_MAC_ADMIN.
>
> Patch 0016 Starts the process of changing how a security
> context is represented. Since it is possible for a
> security context to have been generated by more than one
> security module it is now necessary to note which module
> created a security context so that the correct "release"
> hook can be called. There are several places where the
> module that created a security context cannot be inferred.
>
> This is achieved by introducing a "lsmcontext" structure
> which contains the context string, its length and the
> "slot" number of the security module that created it.
> The security_release_secctx() interface is changed,
> replacing the (string,len) pointer pair with a lsmcontext
> pointer.
>
> Patches 0017-0019 convert the security interfaces from
> (string,len) pointer pairs to a lsmcontext pointer.
> The slot number identifying the creating module is
> added by the infrastructure. Where the security context
> is stored for extended periods the data type is changed.
>
> The Netlabel code is converted to save lsmblob structures
> instead of secids in Patches 0020-21.
>
> Patch 0022 adds checks to the SELinux binder hooks
> which verify that if either "display" used is SELinux
> both are.
>
> Patches 0023-24 add addition data to the audit records
> to identify the LSM specific data for all active
> modules.
>
> Patches 0025-0027 add new interfaces for getting the
> compound security contexts.
>
> Finally, with all interference on the AppArmor hooks
> removed, Patch 0028 removes the exclusive bit from
> AppArmor. An unnecessary stub hook was also removed.
>
> The Ubuntu project is using an earlier version of
> this patchset in their distribution to enable stacking
> for containers.
>
> Performance measurements to date have the change
> within the "noise". The sockperf and dbench results
> are on the order of 0.2% to 0.8% difference, with
> better performance being as common as worse. The
> benchmarks were run with AppArmor and Smack on Ubuntu.
>
> https://github.com/cschaufler/lsm-stacking.git#stack-5.2-v8-apparmor
>
> Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
> ---
> arch/alpha/include/uapi/asm/socket.h | 1 +
> arch/mips/include/uapi/asm/socket.h | 1 +
> arch/parisc/include/uapi/asm/socket.h | 1 +
> arch/sparc/include/uapi/asm/socket.h | 1 +
> drivers/android/binder.c | 24 +-
> fs/kernfs/dir.c | 5 +-
> fs/kernfs/inode.c | 35 +-
> fs/kernfs/kernfs-internal.h | 3 +-
> fs/nfs/nfs4proc.c | 22 +-
> fs/nfsd/nfs4xdr.c | 20 +-
> fs/proc/base.c | 2 +
> include/linux/audit.h | 1 +
> include/linux/cred.h | 3 +-
> include/linux/lsm_hooks.h | 39 +-
> include/linux/security.h | 184 ++++++++--
> include/net/af_unix.h | 2 +-
> include/net/netlabel.h | 8 +-
> include/net/scm.h | 15 +-
> include/uapi/asm-generic/socket.h | 1 +
> kernel/audit.c | 70 +++-
> kernel/audit.h | 9 +-
> kernel/audit_fsnotify.c | 1 +
> kernel/auditfilter.c | 10 +-
> kernel/auditsc.c | 129 ++++---
> kernel/cred.c | 12 +-
> net/core/sock.c | 7 +-
> net/ipv4/cipso_ipv4.c | 6 +-
> net/ipv4/ip_sockglue.c | 12 +-
> net/netfilter/nf_conntrack_netlink.c | 20 +-
> net/netfilter/nf_conntrack_standalone.c | 11 +-
> net/netfilter/nfnetlink_queue.c | 26 +-
> net/netfilter/nft_meta.c | 13 +-
> net/netfilter/xt_SECMARK.c | 5 +-
> net/netlabel/netlabel_kapi.c | 6 +-
> net/netlabel/netlabel_unlabeled.c | 98 ++---
> net/netlabel/netlabel_unlabeled.h | 2 +-
> net/netlabel/netlabel_user.c | 13 +-
> net/netlabel/netlabel_user.h | 6 +-
> net/unix/af_unix.c | 6 +-
> net/xfrm/xfrm_policy.c | 2 +
> net/xfrm/xfrm_state.c | 2 +
> security/apparmor/include/net.h | 6 +-
> security/apparmor/lsm.c | 85 ++---
> security/commoncap.c | 7 +-
> security/inode.c | 22 +-
> security/integrity/ima/ima.h | 14 +-
> security/integrity/ima/ima_api.c | 10 +-
> security/integrity/ima/ima_appraise.c | 6 +-
> security/integrity/ima/ima_main.c | 36 +-
> security/integrity/ima/ima_policy.c | 19 +-
> security/integrity/integrity_audit.c | 1 +
> security/loadpin/loadpin.c | 8 +-
> security/safesetid/lsm.c | 8 +-
> security/security.c | 632 +++++++++++++++++++++++++++++---
> security/selinux/hooks.c | 213 +++++------
> security/selinux/include/objsec.h | 18 +
> security/selinux/include/security.h | 1 +
> security/selinux/netlabel.c | 25 +-
> security/selinux/ss/services.c | 7 +-
> security/smack/smack.h | 19 +
> security/smack/smack_lsm.c | 185 +++++-----
> security/smack/smack_netfilter.c | 8 +-
> security/smack/smackfs.c | 10 +-
> security/tomoyo/tomoyo.c | 8 +-
> security/yama/yama_lsm.c | 7 +-
> 65 files changed, 1503 insertions(+), 686 deletions(-)
>
^ permalink raw reply
* [PATCH v2] KEYS: trusted: correctly initialize digests and fix locking issue
From: Roberto Sassu @ 2019-09-04 18:50 UTC (permalink / raw)
To: jarkko.sakkinen, zohar
Cc: linux-integrity, linux-security-module, keyrings, linux-kernel,
silviu.vlasceanu, Roberto Sassu
This patch fixes two issues introduced with commit 0b6cf6b97b7e ("tpm: pass
an array of tpm_extend_digest structures to tpm_pcr_extend()").
It initializes the algorithm in init_digests() for trusted keys, and moves
the algorithm check in tpm_pcr_extend() before locks are taken in
tpm_find_get_ops().
Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
Fixes: 0b6cf6b97b7e ("tpm: pass an array of tpm_extend_digest structures to tpm_pcr_extend()")
---
drivers/char/tpm/tpm-interface.c | 8 ++++----
security/keys/trusted.c | 5 +++++
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index 1b4f95c13e00..1fffa91fc148 100644
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -316,14 +316,14 @@ int tpm_pcr_extend(struct tpm_chip *chip, u32 pcr_idx,
int rc;
int i;
- chip = tpm_find_get_ops(chip);
- if (!chip)
- return -ENODEV;
-
for (i = 0; i < chip->nr_allocated_banks; i++)
if (digests[i].alg_id != chip->allocated_banks[i].alg_id)
return -EINVAL;
+ chip = tpm_find_get_ops(chip);
+ if (!chip)
+ return -ENODEV;
+
if (chip->flags & TPM_CHIP_FLAG_TPM2) {
rc = tpm2_pcr_extend(chip, pcr_idx, digests);
tpm_put_ops(chip);
diff --git a/security/keys/trusted.c b/security/keys/trusted.c
index ade699131065..1fbd77816610 100644
--- a/security/keys/trusted.c
+++ b/security/keys/trusted.c
@@ -1228,11 +1228,16 @@ static int __init trusted_shash_alloc(void)
static int __init init_digests(void)
{
+ int i;
+
digests = kcalloc(chip->nr_allocated_banks, sizeof(*digests),
GFP_KERNEL);
if (!digests)
return -ENOMEM;
+ for (i = 0; i < chip->nr_allocated_banks; i++)
+ digests[i].alg_id = chip->allocated_banks[i].alg_id;
+
return 0;
}
--
2.17.1
^ permalink raw reply related
* [PATCH] KEYS: trusted: correctly initialize digests and fix locking issue
From: Roberto Sassu @ 2019-09-04 17:23 UTC (permalink / raw)
To: jarkko.sakkinen, zohar
Cc: linux-integrity, linux-security-module, keyrings, linux-kernel,
silviu.vlasceanu, Roberto Sassu
This patch fixes two issues introduced with commit 240730437deb ("KEYS:
trusted: explicitly use tpm_chip structure from tpm_default_chip()").
It initializes the algorithm in init_digests() for trusted keys, and moves
the algorithm check in tpm_pcr_extend() before locks are taken in
tpm_find_get_ops().
Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
Fixes: 240730437deb ("KEYS: trusted: explicitly use tpm_chip structure from tpm_default_chip()")
---
drivers/char/tpm/tpm-interface.c | 8 ++++----
security/keys/trusted.c | 5 +++++
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index 1b4f95c13e00..1fffa91fc148 100644
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -316,14 +316,14 @@ int tpm_pcr_extend(struct tpm_chip *chip, u32 pcr_idx,
int rc;
int i;
- chip = tpm_find_get_ops(chip);
- if (!chip)
- return -ENODEV;
-
for (i = 0; i < chip->nr_allocated_banks; i++)
if (digests[i].alg_id != chip->allocated_banks[i].alg_id)
return -EINVAL;
+ chip = tpm_find_get_ops(chip);
+ if (!chip)
+ return -ENODEV;
+
if (chip->flags & TPM_CHIP_FLAG_TPM2) {
rc = tpm2_pcr_extend(chip, pcr_idx, digests);
tpm_put_ops(chip);
diff --git a/security/keys/trusted.c b/security/keys/trusted.c
index ade699131065..1fbd77816610 100644
--- a/security/keys/trusted.c
+++ b/security/keys/trusted.c
@@ -1228,11 +1228,16 @@ static int __init trusted_shash_alloc(void)
static int __init init_digests(void)
{
+ int i;
+
digests = kcalloc(chip->nr_allocated_banks, sizeof(*digests),
GFP_KERNEL);
if (!digests)
return -ENOMEM;
+ for (i = 0; i < chip->nr_allocated_banks; i++)
+ digests[i].alg_id = chip->allocated_banks[i].alg_id;
+
return 0;
}
--
2.17.1
^ permalink raw reply related
* Re: [PATCH V40 04/29] lockdown: Enforce module signatures if the kernel is locked down
From: Matthew Garrett @ 2019-09-04 16:57 UTC (permalink / raw)
To: David Howells
Cc: James Morris, LSM List, Linux Kernel Mailing List, Linux API,
Kees Cook, Jessica Yu
In-Reply-To: <3638.1567182673@warthog.procyon.org.uk>
On Fri, Aug 30, 2019 at 9:31 AM David Howells <dhowells@redhat.com> wrote:
>
> Matthew Garrett <matthewgarrett@google.com> wrote:
>
> > enum lockdown_reason {
> > LOCKDOWN_NONE,
> > + LOCKDOWN_MODULE_SIGNATURE,
> > LOCKDOWN_INTEGRITY_MAX,
> > LOCKDOWN_CONFIDENTIALITY_MAX,
> > };
>
> Aren't you mixing disjoint sets?
The goal is to be able to check whether any given lockdown reason is a
matter of integrity or confidentiality in a straightforward way.
> > + [LOCKDOWN_MODULE_SIGNATURE] = "unsigned module loading",
>
> Wouldn't it be better to pass this string as a parameter to
> security_locked_down()?
I thought about that, but it's not how any other LSM hooks behave. I
think it's probably easier to revisit that when we see how other LSMs
want to make use of the data.
^ permalink raw reply
* Re: [PATCH V40 03/29] security: Add a static lockdown policy LSM
From: Matthew Garrett @ 2019-09-04 16:51 UTC (permalink / raw)
To: David Howells
Cc: James Morris, LSM List, Linux Kernel Mailing List, Linux API,
Kees Cook
In-Reply-To: <3440.1567182506@warthog.procyon.org.uk>
On Fri, Aug 30, 2019 at 9:28 AM David Howells <dhowells@redhat.com> wrote:
>
> Matthew Garrett <matthewgarrett@google.com> wrote:
>
> > +static char *lockdown_reasons[LOCKDOWN_CONFIDENTIALITY_MAX+1] = {
>
> const char *const maybe?
Seems reasonable.
> > +static enum lockdown_reason lockdown_levels[] = {LOCKDOWN_NONE,
> > + LOCKDOWN_INTEGRITY_MAX,
> > + LOCKDOWN_CONFIDENTIALITY_MAX};
> > +
>
> const?
>
> Isn't this also a 1:1 mapping?
Sorry, a 1:1 mapping to what?
> > +static int lock_kernel_down(const char *where, enum lockdown_reason level)
>
> Is the last parameter the reason or the level? You're mixing the terms.
Fair.
^ permalink raw reply
* Re: Should PCI "new_id" support be disabled when kernel is locked down?
From: Matthew Garrett @ 2019-09-04 16:47 UTC (permalink / raw)
To: Ian Abbott; +Cc: LSM List, linux-pci
In-Reply-To: <cf90a8aa-536e-f4df-0b2f-60724e4034fb@mev.co.uk>
On Wed, Sep 4, 2019 at 9:12 AM Ian Abbott <abbotti@mev.co.uk> wrote:
>
> Hello,
>
> The "new_id" PCI driver sysfs attribute can be used to make an arbitrary
> PCI driver match an arbitrary PCI vendor/device ID. That could easily
> crash the kernel or at least make it do weird things if used
> inappropriately. Is this scenario in scope for the "lockdown" security
> module?
Crashing the kernel isn't really a concern - the issue is more whether
it's possible to get a driver to perform a sufficient number of writes
to a device that it can in turn cause the device to overwrite the
kernel in a controlled manner. This seems theoretically possible, but
I think I'm inclined to leave it as is unless someone demonstrates
that it's more than theoretical.
^ permalink raw reply
* Re: [PATCH] selinux: fix residual uses of current_security() for the SELinux blob
From: John Johansen @ 2019-09-04 16:46 UTC (permalink / raw)
To: Stephen Smalley, paul
Cc: keescook, casey, selinux, linux-security-module, jmorris,
dhowells
In-Reply-To: <38c27c97-d525-9afb-3f2d-9d3190444ae2@tycho.nsa.gov>
On 9/4/19 8:31 AM, Stephen Smalley wrote:
> On 9/4/19 10:32 AM, Stephen Smalley wrote:
>> We need to use selinux_cred() to fetch the SELinux cred blob instead
>> of directly using current->security or current_security(). There
>> were a couple of lingering uses of current_security() in the SELinux code
>> that were apparently missed during the earlier conversions. IIUC, this
>> would only manifest as a bug if multiple security modules including
>> SELinux are enabled and SELinux is not first in the lsm order.
>
> To further qualify that, it would only manifest as a bug if multiple non-exclusive security modules that use the cred security blob are enabled and SELinux is not first. I don't think that is possible today in existing upstream kernels since the cred blob-using modules are currently all exclusive and tomoyo switched to using the task security blob instead. Obviously that will change if/when the stacking for AA support lands and may already be an issue in Ubuntu depending on what stacking patchsets and what lsm order it is using.
Yes currently SELinux needs to be first in the stack for a few reasons. I haven't really played a lot with full SELinux and AA policy at the host level, instead focusing on running an Ubuntu container on an selinux based host. With SELinux and AA competing for userspace interfaces it currently only makes sense to specify SELinux first. I may have run into this bug when messing with the selinux namespacing patches to experiment with flipping the container order but there are enough other problems with that series that I can't say for sure.
>
>> After
>> this change, there appear to be no other users of current_security()
>> in-tree; perhaps we should remove it altogether.
>>
>> Fixes: bbd3662a8348 ("Infrastructure management of the cred security blob")
>> Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
>> ---
>> security/selinux/hooks.c | 2 +-
>> security/selinux/include/objsec.h | 20 ++++++++++----------
>> 2 files changed, 11 insertions(+), 11 deletions(-)
>>
>> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
>> index d55571c585ff..f1b763eceef9 100644
>> --- a/security/selinux/hooks.c
>> +++ b/security/selinux/hooks.c
>> @@ -3435,7 +3435,7 @@ static int selinux_inode_copy_up_xattr(const char *name)
>> static int selinux_kernfs_init_security(struct kernfs_node *kn_dir,
>> struct kernfs_node *kn)
>> {
>> - const struct task_security_struct *tsec = current_security();
>> + const struct task_security_struct *tsec = selinux_cred(current_cred());
>> u32 parent_sid, newsid, clen;
>> int rc;
>> char *context;
>> diff --git a/security/selinux/include/objsec.h b/security/selinux/include/objsec.h
>> index 231262d8eac9..d2e00c7595dd 100644
>> --- a/security/selinux/include/objsec.h
>> +++ b/security/selinux/include/objsec.h
>> @@ -40,16 +40,6 @@ struct task_security_struct {
>> u32 sockcreate_sid; /* fscreate SID */
>> };
>> -/*
>> - * get the subjective security ID of the current task
>> - */
>> -static inline u32 current_sid(void)
>> -{
>> - const struct task_security_struct *tsec = current_security();
>> -
>> - return tsec->sid;
>> -}
>> -
>> enum label_initialized {
>> LABEL_INVALID, /* invalid or not initialized */
>> LABEL_INITIALIZED, /* initialized */
>> @@ -188,4 +178,14 @@ static inline struct ipc_security_struct *selinux_ipc(
>> return ipc->security + selinux_blob_sizes.lbs_ipc;
>> }
>> +/*
>> + * get the subjective security ID of the current task
>> + */
>> +static inline u32 current_sid(void)
>> +{
>> + const struct task_security_struct *tsec = selinux_cred(current_cred());
>> +
>> + return tsec->sid;
>> +}
>> +
>> #endif /* _SELINUX_OBJSEC_H_ */
>>
>
^ permalink raw reply
* Should PCI "new_id" support be disabled when kernel is locked down?
From: Ian Abbott @ 2019-09-04 15:59 UTC (permalink / raw)
To: linux-security-module; +Cc: linux-pci
Hello,
The "new_id" PCI driver sysfs attribute can be used to make an arbitrary
PCI driver match an arbitrary PCI vendor/device ID. That could easily
crash the kernel or at least make it do weird things if used
inappropriately. Is this scenario in scope for the "lockdown" security
module?
--
-=( Ian Abbott <abbotti@mev.co.uk> || Web: www.mev.co.uk )=-
-=( MEV Ltd. is a company registered in England & Wales. )=-
-=( Registered number: 02862268. Registered address: )=-
-=( 15 West Park Road, Bramhall, STOCKPORT, SK7 3JZ, UK. )=-
^ permalink raw reply
* Re: [PATCH] selinux: fix residual uses of current_security() for the SELinux blob
From: Stephen Smalley @ 2019-09-04 15:31 UTC (permalink / raw)
To: paul
Cc: keescook, casey, selinux, linux-security-module, jmorris,
dhowells, John Johansen
In-Reply-To: <20190904143248.7003-1-sds@tycho.nsa.gov>
On 9/4/19 10:32 AM, Stephen Smalley wrote:
> We need to use selinux_cred() to fetch the SELinux cred blob instead
> of directly using current->security or current_security(). There
> were a couple of lingering uses of current_security() in the SELinux code
> that were apparently missed during the earlier conversions. IIUC, this
> would only manifest as a bug if multiple security modules including
> SELinux are enabled and SELinux is not first in the lsm order.
To further qualify that, it would only manifest as a bug if multiple
non-exclusive security modules that use the cred security blob are
enabled and SELinux is not first. I don't think that is possible today
in existing upstream kernels since the cred blob-using modules are
currently all exclusive and tomoyo switched to using the task security
blob instead. Obviously that will change if/when the stacking for AA
support lands and may already be an issue in Ubuntu depending on what
stacking patchsets and what lsm order it is using.
> After
> this change, there appear to be no other users of current_security()
> in-tree; perhaps we should remove it altogether.
>
> Fixes: bbd3662a8348 ("Infrastructure management of the cred security blob")
> Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
> ---
> security/selinux/hooks.c | 2 +-
> security/selinux/include/objsec.h | 20 ++++++++++----------
> 2 files changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index d55571c585ff..f1b763eceef9 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -3435,7 +3435,7 @@ static int selinux_inode_copy_up_xattr(const char *name)
> static int selinux_kernfs_init_security(struct kernfs_node *kn_dir,
> struct kernfs_node *kn)
> {
> - const struct task_security_struct *tsec = current_security();
> + const struct task_security_struct *tsec = selinux_cred(current_cred());
> u32 parent_sid, newsid, clen;
> int rc;
> char *context;
> diff --git a/security/selinux/include/objsec.h b/security/selinux/include/objsec.h
> index 231262d8eac9..d2e00c7595dd 100644
> --- a/security/selinux/include/objsec.h
> +++ b/security/selinux/include/objsec.h
> @@ -40,16 +40,6 @@ struct task_security_struct {
> u32 sockcreate_sid; /* fscreate SID */
> };
>
> -/*
> - * get the subjective security ID of the current task
> - */
> -static inline u32 current_sid(void)
> -{
> - const struct task_security_struct *tsec = current_security();
> -
> - return tsec->sid;
> -}
> -
> enum label_initialized {
> LABEL_INVALID, /* invalid or not initialized */
> LABEL_INITIALIZED, /* initialized */
> @@ -188,4 +178,14 @@ static inline struct ipc_security_struct *selinux_ipc(
> return ipc->security + selinux_blob_sizes.lbs_ipc;
> }
>
> +/*
> + * get the subjective security ID of the current task
> + */
> +static inline u32 current_sid(void)
> +{
> + const struct task_security_struct *tsec = selinux_cred(current_cred());
> +
> + return tsec->sid;
> +}
> +
> #endif /* _SELINUX_OBJSEC_H_ */
>
^ permalink raw reply
* Re: [PATCH 08/11] usb: Add USB subsystem notifications [ver #7]
From: David Howells @ 2019-09-04 15:17 UTC (permalink / raw)
To: Alan Stern
Cc: dhowells, Guenter Roeck, viro, Casey Schaufler, Stephen Smalley,
Greg Kroah-Hartman, nicolas.dichtel, raven, Christian Brauner,
keyrings, linux-usb, linux-security-module, linux-fsdevel,
linux-api, linux-block, linux-kernel
In-Reply-To: <Pine.LNX.4.44L0.1909031316130.1859-100000@iolanthe.rowland.org>
Alan Stern <stern@rowland.harvard.edu> wrote:
> > > Unfortunately, I don't know how to fix it and don't have much time to
> > > investigate it right now - and it's something that can be added back later.
> >
> > The cause of your problem is quite simple:
> >
> > static int usbdev_notify(struct notifier_block *self,
> > unsigned long action, void *dev)
> > {
> > switch (action) {
> > case USB_DEVICE_ADD:
> > + post_usb_device_notification(dev, NOTIFY_USB_DEVICE_ADD, 0);
> > break;
> > case USB_DEVICE_REMOVE:
> > + post_usb_device_notification(dev, NOTIFY_USB_DEVICE_REMOVE, 0);
> > + usbdev_remove(dev);
> > + break;
> > + case USB_BUS_ADD:
> > + post_usb_bus_notification(dev, NOTIFY_USB_BUS_ADD, 0);
> > + break;
> > + case USB_BUS_REMOVE:
> > + post_usb_bus_notification(dev, NOTIFY_USB_BUS_REMOVE, 0);
> > usbdev_remove(dev);
> > break;
> > }
> >
> > The original code had usbdev_remove(dev) under the USB_DEVICE_REMOVE
> > case. The patch mistakenly moves it, putting it under the
> ------------------------------^^^^^
>
> Sorry, I should have said "duplicates" it.
Ah, thanks. I'd already removed the USB bus notifications, so I'll leave them
out for now.
David
^ permalink raw reply
* Re: [PATCH] selinux: fix residual uses of current_security() for the SELinux blob
From: Casey Schaufler @ 2019-09-04 15:16 UTC (permalink / raw)
To: Stephen Smalley, paul
Cc: keescook, selinux, linux-security-module, jmorris, dhowells,
casey
In-Reply-To: <20190904143248.7003-1-sds@tycho.nsa.gov>
On 9/4/2019 7:32 AM, Stephen Smalley wrote:
> We need to use selinux_cred() to fetch the SELinux cred blob instead
> of directly using current->security or current_security(). There
> were a couple of lingering uses of current_security() in the SELinux code
> that were apparently missed during the earlier conversions.
Thank you for finding this.
> IIUC, this
> would only manifest as a bug if multiple security modules including
> SELinux are enabled and SELinux is not first in the lsm order. After
> this change, there appear to be no other users of current_security()
> in-tree; perhaps we should remove it altogether.
I agree.
>
> Fixes: bbd3662a8348 ("Infrastructure management of the cred security blob")
> Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Acked-by: Casey Schaufler <casey@schaufler-ca.com>
> ---
> security/selinux/hooks.c | 2 +-
> security/selinux/include/objsec.h | 20 ++++++++++----------
> 2 files changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index d55571c585ff..f1b763eceef9 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -3435,7 +3435,7 @@ static int selinux_inode_copy_up_xattr(const char *name)
> static int selinux_kernfs_init_security(struct kernfs_node *kn_dir,
> struct kernfs_node *kn)
> {
> - const struct task_security_struct *tsec = current_security();
> + const struct task_security_struct *tsec = selinux_cred(current_cred());
> u32 parent_sid, newsid, clen;
> int rc;
> char *context;
> diff --git a/security/selinux/include/objsec.h b/security/selinux/include/objsec.h
> index 231262d8eac9..d2e00c7595dd 100644
> --- a/security/selinux/include/objsec.h
> +++ b/security/selinux/include/objsec.h
> @@ -40,16 +40,6 @@ struct task_security_struct {
> u32 sockcreate_sid; /* fscreate SID */
> };
>
> -/*
> - * get the subjective security ID of the current task
> - */
> -static inline u32 current_sid(void)
> -{
> - const struct task_security_struct *tsec = current_security();
> -
> - return tsec->sid;
> -}
> -
> enum label_initialized {
> LABEL_INVALID, /* invalid or not initialized */
> LABEL_INITIALIZED, /* initialized */
> @@ -188,4 +178,14 @@ static inline struct ipc_security_struct *selinux_ipc(
> return ipc->security + selinux_blob_sizes.lbs_ipc;
> }
>
> +/*
> + * get the subjective security ID of the current task
> + */
> +static inline u32 current_sid(void)
> +{
> + const struct task_security_struct *tsec = selinux_cred(current_cred());
> +
> + return tsec->sid;
> +}
> +
> #endif /* _SELINUX_OBJSEC_H_ */
^ permalink raw reply
* Re: [PATCH 11/11] smack: Implement the watch_key and post_notification hooks [untested] [ver #7]
From: Casey Schaufler @ 2019-09-04 14:56 UTC (permalink / raw)
To: David Howells
Cc: viro, Stephen Smalley, Greg Kroah-Hartman, nicolas.dichtel, raven,
Christian Brauner, keyrings, linux-usb, linux-security-module,
linux-fsdevel, linux-api, linux-block, linux-kernel, casey
In-Reply-To: <31205.1567598939@warthog.procyon.org.uk>
On 9/4/2019 5:08 AM, David Howells wrote:
> Casey Schaufler <casey@schaufler-ca.com> wrote:
>
>> I rebuilt with keys-next, updated the tests again, and now
>> the suite looks to be running trouble free.
> Can I put you down as an Acked-by or something on this patch?
I haven't done anything to see if the patch is actually useful.
I don't have much (read: anything) in the way of key tests for
Smack, so I can't say if this is what I want long term. But as
it does appear harmless, yes, you can add my Acked-by on this.
>
> Thanks,
> David
^ permalink raw reply
* [PATCH] selinux: fix residual uses of current_security() for the SELinux blob
From: Stephen Smalley @ 2019-09-04 14:32 UTC (permalink / raw)
To: paul
Cc: keescook, casey, selinux, linux-security-module, jmorris,
dhowells, Stephen Smalley
We need to use selinux_cred() to fetch the SELinux cred blob instead
of directly using current->security or current_security(). There
were a couple of lingering uses of current_security() in the SELinux code
that were apparently missed during the earlier conversions. IIUC, this
would only manifest as a bug if multiple security modules including
SELinux are enabled and SELinux is not first in the lsm order. After
this change, there appear to be no other users of current_security()
in-tree; perhaps we should remove it altogether.
Fixes: bbd3662a8348 ("Infrastructure management of the cred security blob")
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
---
security/selinux/hooks.c | 2 +-
security/selinux/include/objsec.h | 20 ++++++++++----------
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index d55571c585ff..f1b763eceef9 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -3435,7 +3435,7 @@ static int selinux_inode_copy_up_xattr(const char *name)
static int selinux_kernfs_init_security(struct kernfs_node *kn_dir,
struct kernfs_node *kn)
{
- const struct task_security_struct *tsec = current_security();
+ const struct task_security_struct *tsec = selinux_cred(current_cred());
u32 parent_sid, newsid, clen;
int rc;
char *context;
diff --git a/security/selinux/include/objsec.h b/security/selinux/include/objsec.h
index 231262d8eac9..d2e00c7595dd 100644
--- a/security/selinux/include/objsec.h
+++ b/security/selinux/include/objsec.h
@@ -40,16 +40,6 @@ struct task_security_struct {
u32 sockcreate_sid; /* fscreate SID */
};
-/*
- * get the subjective security ID of the current task
- */
-static inline u32 current_sid(void)
-{
- const struct task_security_struct *tsec = current_security();
-
- return tsec->sid;
-}
-
enum label_initialized {
LABEL_INVALID, /* invalid or not initialized */
LABEL_INITIALIZED, /* initialized */
@@ -188,4 +178,14 @@ static inline struct ipc_security_struct *selinux_ipc(
return ipc->security + selinux_blob_sizes.lbs_ipc;
}
+/*
+ * get the subjective security ID of the current task
+ */
+static inline u32 current_sid(void)
+{
+ const struct task_security_struct *tsec = selinux_cred(current_cred());
+
+ return tsec->sid;
+}
+
#endif /* _SELINUX_OBJSEC_H_ */
--
2.21.0
^ permalink raw reply related
* Re: [PATCH 11/11] smack: Implement the watch_key and post_notification hooks [untested] [ver #7]
From: David Howells @ 2019-09-04 12:08 UTC (permalink / raw)
To: Casey Schaufler
Cc: dhowells, viro, Stephen Smalley, Greg Kroah-Hartman,
nicolas.dichtel, raven, Christian Brauner, keyrings, linux-usb,
linux-security-module, linux-fsdevel, linux-api, linux-block,
linux-kernel
In-Reply-To: <23d61564-026e-b37a-8b16-ce68d5949f6c@schaufler-ca.com>
Casey Schaufler <casey@schaufler-ca.com> wrote:
> I rebuilt with keys-next, updated the tests again, and now
> the suite looks to be running trouble free.
Can I put you down as an Acked-by or something on this patch?
Thanks,
David
^ permalink raw reply
* Re: general protection fault in smack_socket_sendmsg
From: Tetsuo Handa @ 2019-09-04 10:16 UTC (permalink / raw)
To: Casey Schaufler, Hillf Danton, syzbot
Cc: jmorris, linux-kernel, linux-security-module, serge,
syzkaller-bugs
In-Reply-To: <5f34b914-ca5b-e527-9183-64dc0d83ec9f@schaufler-ca.com>
On 2019/09/04 8:17, Casey Schaufler wrote:
> On 8/30/2019 10:33 PM, Hillf Danton wrote:
>>> dashboard link: https://syzkaller.appspot.com/bug?extid=5fd781d646d4fcbdfeb0
> If you want to add a description and signed-off-by I will take this.
Excuse me, but this bug was already closed as dup of "KASAN: use-after-free Read in rxrpc_send_keepalive".
^ permalink raw reply
* RE: [PATCH 08/11] usb: Add USB subsystem notifications [ver #7]
From: Yoshihiro Shimoda @ 2019-09-04 1:53 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: David Howells, viro@zeniv.linux.org.uk, Casey Schaufler,
Stephen Smalley, nicolas.dichtel@6wind.com, raven@themaw.net,
Christian Brauner, keyrings@vger.kernel.org,
linux-usb@vger.kernel.org, linux-security-module@vger.kernel.org,
linux-fsdevel@vger.kernel.org, linux-api@vger.kernel.org,
linux-block@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20190903093720.GD12325@kroah.com>
Hi Greg,
> From: Greg Kroah-Hartman, Sent: Tuesday, September 3, 2019 6:37 PM
<snip>
> > > +void post_usb_bus_notification(const struct usb_bus *ubus,
> >
> > This function's argument is struct usb_bus *, but ...
> >
> > > + enum usb_notification_type subtype, u32 error)
> > > +{
> > > + post_usb_notification(ubus->bus_name, subtype, error);
> > > +}
> > > +#endif
> > > +
> > > static int usbdev_notify(struct notifier_block *self,
> > > unsigned long action, void *dev)
> > > {
> > > switch (action) {
> > > case USB_DEVICE_ADD:
> > > + post_usb_device_notification(dev, NOTIFY_USB_DEVICE_ADD, 0);
> > > break;
> > > case USB_DEVICE_REMOVE:
> > > + post_usb_device_notification(dev, NOTIFY_USB_DEVICE_REMOVE, 0);
> > > + usbdev_remove(dev);
> > > + break;
> > > + case USB_BUS_ADD:
> > > + post_usb_bus_notification(dev, NOTIFY_USB_BUS_ADD, 0);
> > > + break;
> > > + case USB_BUS_REMOVE:
> > > + post_usb_bus_notification(dev, NOTIFY_USB_BUS_REMOVE, 0);
> > > usbdev_remove(dev);
> >
> > this function calls usbdev_remove() with incorrect argument if the action
> > is USB_BUS_REMOVE. So, this seems to cause the following issue [1] on
> > my environment (R-Car H3 / r8a7795 on next-20190902) [2]. However, I have
> > no idea how to fix the issue, so I report this issue at the first step.
>
> As a few of us just discussed this on IRC, these bus notifiers should
> probably be dropped as these are the incorrect structure type as you
> found out. Thanks for the report.
Thank you for the discussion. I got it.
Best regards,
Yoshihiro Shimoda
> greg k-h
^ permalink raw reply
* Re: general protection fault in smack_socket_sendmsg
From: Casey Schaufler @ 2019-09-03 23:17 UTC (permalink / raw)
To: Hillf Danton, syzbot
Cc: jmorris, linux-kernel, linux-security-module, serge,
syzkaller-bugs, casey
In-Reply-To: <20190831053311.15704-1-hdanton@sina.com>
On 8/30/2019 10:33 PM, Hillf Danton wrote:
> On Fri, 30 Aug 2019 12:40:07 -0700
>> Hello,
>>
>> syzbot found the following crash on:
>>
>> HEAD commit: 6525771f Merge tag 'arc-5.3-rc7' of git://git.kernel.org/p..
>> git tree: upstream
>> console output: https://syzkaller.appspot.com/x/log.txt?x=11486cea600000
>> kernel config: https://syzkaller.appspot.com/x/.config?x=58485246ad14eafe
>> dashboard link: https://syzkaller.appspot.com/bug?extid=5fd781d646d4fcbdfeb0
>> compiler: clang version 9.0.0 (/home/glider/llvm/clang
>> 80fee25776c2fb61e74c1ecb1a523375c2500b69)
>>
>> Unfortunately, I don't have any reproducer for this crash yet.
>>
>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> Reported-by: syzbot+5fd781d646d4fcbdfeb0@syzkaller.appspotmail.com
>>
>> kasan: CONFIG_KASAN_INLINE enabled
>> kasan: GPF could be caused by NULL-ptr deref or user memory access
>> general protection fault: 0000 [#1] PREEMPT SMP KASAN
>> CPU: 0 PID: 11983 Comm: kworker/0:0 Not tainted 5.3.0-rc6+ #94
>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>> Google 01/01/2011
>> Workqueue: krxrpcd rxrpc_peer_keepalive_worker
>> RIP: 0010:smack_socket_sendmsg+0x5b/0x480 security/smack/smack_lsm.c:3677
>> Code: e8 6a 07 71 fe 4c 89 e8 48 c1 e8 03 42 80 3c 38 00 74 08 4c 89 ef e8
>> b4 ff a9 fe 4d 8b 65 00 48 83 c3 18 48 89 d8 48 c1 e8 03 <42> 80 3c 38 00
>> 74 08 48 89 df e8 96 ff a9 fe 4c 8b 33 49 8d 9e 08
>> RSP: 0018:ffff8881daa1f9c8 EFLAGS: 00010206
>> RAX: 0000000000000003 RBX: 0000000000000018 RCX: ffff888048882500
>> RDX: 0000000000000000 RSI: ffff8881daa1fb18 RDI: 0000000000000000
>> RBP: ffff8881daa1fa80 R08: ffffffff8350cc90 R09: ffff8881daa1fb86
>> R10: ffffed103b543f72 R11: 0000000000000000 R12: ffff88803704c594
>> R13: ffff8881daa1fb18 R14: dffffc0000000000 R15: dffffc0000000000
>> FS: 0000000000000000(0000) GS:ffff8880aea00000(0000) knlGS:0000000000000000
>> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> CR2: 00007f7d4f2b5028 CR3: 000000005e835000 CR4: 00000000001426f0
>> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
>> Call Trace:
>> security_socket_sendmsg+0x6c/0xd0 security/security.c:1973
>> sock_sendmsg net/socket.c:654 [inline]
>> kernel_sendmsg+0x77/0x140 net/socket.c:677
>> rxrpc_send_keepalive+0x254/0x3c0 net/rxrpc/output.c:655
>> rxrpc_peer_keepalive_dispatch net/rxrpc/peer_event.c:369 [inline]
>> rxrpc_peer_keepalive_worker+0x76e/0xb40 net/rxrpc/peer_event.c:430
>> process_one_work+0x7ef/0x10e0 kernel/workqueue.c:2269
>> worker_thread+0xc01/0x1630 kernel/workqueue.c:2415
>> kthread+0x332/0x350 kernel/kthread.c:255
>> ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
>> Modules linked in:
>> ---[ end trace 61235a384085b26a ]---
If you want to add a description and signed-off-by I will take this.
>
> --- a/security/smack/smack_lsm.c
> +++ b/security/smack/smack_lsm.c
> @@ -3674,7 +3674,7 @@ static int smack_socket_sendmsg(struct s
> struct sockaddr_in6 *sap = (struct sockaddr_in6 *) msg->msg_name;
> #endif
> #ifdef SMACK_IPV6_SECMARK_LABELING
> - struct socket_smack *ssp = sock->sk->sk_security;
> + struct socket_smack *ssp;
> struct smack_known *rsp;
> #endif
> int rc = 0;
> @@ -3684,6 +3684,15 @@ static int smack_socket_sendmsg(struct s
> */
> if (sip == NULL)
> return 0;
> + /*
> + * Fine if sock reaped
> + */
> + if (!READ_ONCE(sock->sk))
> + return 0;
> +
> +#ifdef SMACK_IPV6_SECMARK_LABELING
> + ssp = sock->sk->sk_security;
> +#endif
>
> switch (sock->sk->sk_family) {
> case AF_INET:
>
^ permalink raw reply
* Re: [PATCH 11/11] smack: Implement the watch_key and post_notification hooks [untested] [ver #7]
From: David Howells @ 2019-09-03 22:39 UTC (permalink / raw)
To: Casey Schaufler
Cc: dhowells, viro, Stephen Smalley, Greg Kroah-Hartman,
nicolas.dichtel, raven, Christian Brauner, keyrings, linux-usb,
linux-security-module, linux-fsdevel, linux-api, linux-block,
linux-kernel
In-Reply-To: <23d61564-026e-b37a-8b16-ce68d5949f6c@schaufler-ca.com>
Casey Schaufler <casey@schaufler-ca.com> wrote:
> I rebuilt with keys-next, updated the tests again, and now
> the suite looks to be running trouble free.
Glad to hear that, thanks.
> I do see a message SKIP DUE TO DISABLED SELINUX which I take to mean that
> there is an SELinux specific test.
tests/bugzillas/bz1031154/runtest.sh
David
^ permalink raw reply
* Re: [PATCH 11/11] smack: Implement the watch_key and post_notification hooks [untested] [ver #7]
From: Casey Schaufler @ 2019-09-03 22:16 UTC (permalink / raw)
To: David Howells
Cc: viro, Stephen Smalley, Greg Kroah-Hartman, nicolas.dichtel, raven,
Christian Brauner, keyrings, linux-usb, linux-security-module,
linux-fsdevel, linux-api, linux-block, linux-kernel, casey
In-Reply-To: <11467.1567534014@warthog.procyon.org.uk>
On 9/3/2019 11:06 AM, David Howells wrote:
> Casey Schaufler <casey@schaufler-ca.com> wrote:
>
>> Built from your tree.
> What branch? keys-next?
I rebuilt with keys-next, updated the tests again, and now
the suite looks to be running trouble free. I do see a message
SKIP DUE TO DISABLED SELINUX which I take to mean that there
is an SELinux specific test.
>
>> keyctl move 483362336 1065401533 @s
>> keyctl_move: Operation not supported
> Odd. That should be unconditional if you have CONFIG_KEYS and v5.3-rc1. Can
> you try:
>
> keyctl supports
>
> or just:
>
> keyctl add user a a @s
>
> which will give you an id, say 1234, then:
>
> keyctl move 1234 @s @u
>
> see if that works.
>
> David
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox