* Re: [RFC PATCH v9 2/3] arch: Wire up introspect_access(2)
From: Arnd Bergmann @ 2020-09-15 13:32 UTC (permalink / raw)
To: Mickaël Salaün
Cc: linux-kernel@vger.kernel.org, Aleksa Sarai, Alexei Starovoitov,
Al Viro, Andrew Morton, Andy Lutomirski, Casey Schaufler,
Christian Brauner, Christian Heimes, Daniel Borkmann,
Deven Bowers, Dmitry Vyukov, Eric Biggers, Eric Chiang,
Florian Weimer, James Morris, Jan Kara, Jann Horn,
Jonathan Corbet, Kees Cook, Lakshmi Ramasubramanian,
Matthew Garrett, Matthew Wilcox, Michael Kerrisk, Miklos Szeredi,
Mimi Zohar, Philippe Trébuchet, Scott Shell,
Sean Christopherson, Shuah Khan, Steve Dower, Steve Grubb,
Tetsuo Handa, Thibaut Sautereau, Vincent Strubel,
Kernel Hardening, Linux API, linux-integrity, LSM List,
Linux FS-devel Mailing List, Mickaël Salaün,
Thibaut Sautereau
In-Reply-To: <20200910164612.114215-3-mic@digikod.net>
On Thu, Sep 10, 2020 at 6:46 PM Mickaël Salaün <mic@digikod.net> wrote:
>
> From: Mickaël Salaün <mic@linux.microsoft.com>
>
> Wire up access_interpreted(2) for all architectures.
>
> Signed-off-by: Mickaël Salaün <mic@linux.microsoft.com>
> Reviewed-by: Thibaut Sautereau <thibaut.sautereau@ssi.gouv.fr>
> Cc: Al Viro <viro@zeniv.linux.org.uk>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Kees Cook <keescook@chromium.org>
> Cc: Vincent Strubel <vincent.strubel@ssi.gouv.fr>
> ---
>
> Changes since v7:
> * New patch for the new syscall.
> * Increase syscall numbers by 2 to leave space for new ones (in
> linux-next): watch_mount(2) and process_madvise(2).
I checked that the syscall calling conventions are sane and that
it is wired up correctly on all architectures in this patch.
Acked-by: Arnd Bergmann <arnd@arndb.de>
I did not look at the system call implementation or its purpose though,
as that is not my area.
^ permalink raw reply
* [PATCH v38 15/24] x86/sgx: Enable provisioning for remote attestation
From: Jarkko Sakkinen @ 2020-09-15 11:05 UTC (permalink / raw)
To: x86, linux-sgx
Cc: linux-kernel, Jarkko Sakkinen, linux-security-module,
Jethro Beekman, Darren Kenny, Andy Lutomirski, akpm,
andriy.shevchenko, asapek, bp, cedric.xing, chenalexchen,
conradparker, cyhanish, dave.hansen, haitao.huang, josh,
kai.huang, kai.svahn, kmoy, ludloff, nhorman, npmccallum,
puiterwijk, rientjes, sean.j.christopherson, tglx, yaozhangx
In-Reply-To: <20200915110522.893152-1-jarkko.sakkinen@linux.intel.com>
Provisioning Certification Enclave (PCE), the root of trust for other
enclaves, generates a signing key from a fused key called Provisioning
Certification Key. PCE can then use this key to certify an attestation key
of a Quoting Enclave (QE), e.g. we get the chain of trust down to the
hardware if the Intel signed PCE is used.
To use the needed keys, ATTRIBUTE.PROVISIONKEY is required but should be
only allowed for those who actually need it so that only the trusted
parties can certify QE's.
Obviously the attestation service should know the public key of the used
PCE and that way detect illegit attestation, but whitelisting the legit
users still adds an additional layer of defence.
Add new device file called /dev/sgx/provision. The sole purpose of this
file is to provide file descriptors that act as privilege tokens to allow
to build enclaves with ATTRIBUTE.PROVISIONKEY set. A new ioctl called
SGX_IOC_ENCLAVE_PROVISION is used to assign this token to an enclave.
Cc: linux-security-module@vger.kernel.org
Acked-by: Jethro Beekman <jethro@fortanix.com>
Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
Suggested-by: Andy Lutomirski <luto@kernel.org>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
---
arch/x86/include/uapi/asm/sgx.h | 11 ++++++++
arch/x86/kernel/cpu/sgx/driver.c | 18 ++++++++++++
arch/x86/kernel/cpu/sgx/driver.h | 2 ++
arch/x86/kernel/cpu/sgx/ioctl.c | 47 ++++++++++++++++++++++++++++++++
4 files changed, 78 insertions(+)
diff --git a/arch/x86/include/uapi/asm/sgx.h b/arch/x86/include/uapi/asm/sgx.h
index 7729730d8580..d0916fb9629e 100644
--- a/arch/x86/include/uapi/asm/sgx.h
+++ b/arch/x86/include/uapi/asm/sgx.h
@@ -25,6 +25,8 @@ enum sgx_page_flags {
_IOWR(SGX_MAGIC, 0x01, struct sgx_enclave_add_pages)
#define SGX_IOC_ENCLAVE_INIT \
_IOW(SGX_MAGIC, 0x02, struct sgx_enclave_init)
+#define SGX_IOC_ENCLAVE_PROVISION \
+ _IOW(SGX_MAGIC, 0x03, struct sgx_enclave_provision)
/**
* struct sgx_enclave_create - parameter structure for the
@@ -61,4 +63,13 @@ struct sgx_enclave_init {
__u64 sigstruct;
};
+/**
+ * struct sgx_enclave_provision - parameter structure for the
+ * %SGX_IOC_ENCLAVE_PROVISION ioctl
+ * @attribute_fd: file handle of the attribute file in the securityfs
+ */
+struct sgx_enclave_provision {
+ __u64 attribute_fd;
+};
+
#endif /* _UAPI_ASM_X86_SGX_H */
diff --git a/arch/x86/kernel/cpu/sgx/driver.c b/arch/x86/kernel/cpu/sgx/driver.c
index 7bdb49dfcca6..d01b28f7ce4a 100644
--- a/arch/x86/kernel/cpu/sgx/driver.c
+++ b/arch/x86/kernel/cpu/sgx/driver.c
@@ -134,6 +134,10 @@ static const struct file_operations sgx_encl_fops = {
.get_unmapped_area = sgx_get_unmapped_area,
};
+const struct file_operations sgx_provision_fops = {
+ .owner = THIS_MODULE,
+};
+
static struct miscdevice sgx_dev_enclave = {
.minor = MISC_DYNAMIC_MINOR,
.name = "enclave",
@@ -141,6 +145,13 @@ static struct miscdevice sgx_dev_enclave = {
.fops = &sgx_encl_fops,
};
+static struct miscdevice sgx_dev_provision = {
+ .minor = MISC_DYNAMIC_MINOR,
+ .name = "provision",
+ .nodename = "sgx/provision",
+ .fops = &sgx_provision_fops,
+};
+
int __init sgx_drv_init(void)
{
unsigned int eax, ebx, ecx, edx;
@@ -181,5 +192,12 @@ int __init sgx_drv_init(void)
return ret;
}
+ ret = misc_register(&sgx_dev_provision);
+ if (ret) {
+ pr_err("Creating /dev/sgx/provision failed with %d.\n", ret);
+ misc_deregister(&sgx_dev_enclave);
+ return ret;
+ }
+
return 0;
}
diff --git a/arch/x86/kernel/cpu/sgx/driver.h b/arch/x86/kernel/cpu/sgx/driver.h
index e4063923115b..72747d01c046 100644
--- a/arch/x86/kernel/cpu/sgx/driver.h
+++ b/arch/x86/kernel/cpu/sgx/driver.h
@@ -23,6 +23,8 @@ extern u64 sgx_attributes_reserved_mask;
extern u64 sgx_xfrm_reserved_mask;
extern u32 sgx_xsave_size_tbl[64];
+extern const struct file_operations sgx_provision_fops;
+
long sgx_ioctl(struct file *filep, unsigned int cmd, unsigned long arg);
int sgx_drv_init(void);
diff --git a/arch/x86/kernel/cpu/sgx/ioctl.c b/arch/x86/kernel/cpu/sgx/ioctl.c
index de2ed4f35ffb..4227bca7b477 100644
--- a/arch/x86/kernel/cpu/sgx/ioctl.c
+++ b/arch/x86/kernel/cpu/sgx/ioctl.c
@@ -673,6 +673,50 @@ static long sgx_ioc_enclave_init(struct sgx_encl *encl, void __user *arg)
return ret;
}
+/**
+ * sgx_ioc_enclave_set_attribute - handler for %SGX_IOC_ENCLAVE_PROVISION
+ * @filep: open file to /dev/sgx
+ * @arg: userspace pointer to a struct sgx_enclave_provision instance
+ *
+ * Mark the enclave as being allowed to access a restricted attribute bit.
+ * The requested attribute is specified via the attribute_fd field in the
+ * provided struct sgx_enclave_provision. The attribute_fd must be a
+ * handle to an SGX attribute file, e.g. "/dev/sgx/provision".
+ *
+ * Failure to explicitly request access to a restricted attribute will cause
+ * sgx_ioc_enclave_init() to fail. Currently, the only restricted attribute
+ * is access to the PROVISION_KEY.
+ *
+ * Note, access to the EINITTOKEN_KEY is disallowed entirely.
+ *
+ * Return: 0 on success, -errno otherwise
+ */
+static long sgx_ioc_enclave_provision(struct sgx_encl *encl,
+ void __user *arg)
+{
+ struct sgx_enclave_provision params;
+ struct file *attribute_file;
+ int ret;
+
+ if (copy_from_user(¶ms, arg, sizeof(params)))
+ return -EFAULT;
+
+ attribute_file = fget(params.attribute_fd);
+ if (!attribute_file)
+ return -EINVAL;
+
+ if (attribute_file->f_op != &sgx_provision_fops) {
+ ret = -EINVAL;
+ goto out;
+ }
+
+ encl->attributes |= SGX_ATTR_PROVISIONKEY;
+ ret = 0;
+
+out:
+ fput(attribute_file);
+ return ret;
+}
long sgx_ioctl(struct file *filep, unsigned int cmd, unsigned long arg)
{
@@ -698,6 +742,9 @@ long sgx_ioctl(struct file *filep, unsigned int cmd, unsigned long arg)
case SGX_IOC_ENCLAVE_INIT:
ret = sgx_ioc_enclave_init(encl, (void __user *)arg);
break;
+ case SGX_IOC_ENCLAVE_PROVISION:
+ ret = sgx_ioc_enclave_provision(encl, (void __user *)arg);
+ break;
default:
ret = -ENOIOCTLCMD;
break;
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v2] socket.7,unix.7: add initial description for SO_PEERSEC
From: Michael Kerrisk (man-pages) @ 2020-09-15 8:56 UTC (permalink / raw)
To: Stephen Smalley
Cc: linux-man, linux-security-module, selinux, smcv, James Morris,
Serge E. Hallyn, Michael Kerrisk
In-Reply-To: <20200914180700.11003-1-stephen.smalley.work@gmail.com>
Hello Stephen,
On Mon, 14 Sep 2020 at 20:07, Stephen Smalley
<stephen.smalley.work@gmail.com> wrote:
>
> SO_PEERSEC was introduced for AF_UNIX stream sockets connected via
> connect(2) in Linux 2.6.2 [1] and later augmented to support AF_UNIX stream
> and datagram sockets created via socketpair(2) in Linux 4.18 [2]. Document
> SO_PEERSEC in the socket.7 and unix.7 man pages following the example
> of the existing SO_PEERCRED descriptions. SO_PEERSEC is also supported
> on AF_INET sockets when using labeled IPSEC or NetLabel but defer
> adding a description of that support to a separate patch.
>
> The module-independent description of the security context returned
> by SO_PEERSEC is from Simon McVittie <smcv@collabora.com>.
Thanks for the patch, The text looks in reasonable shape to me. I'm
just hanging off applying for a bit in case some Reviewed/Acked-by
comes in.
Cheers,
Michael
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/commit/?id=da6e57a2e6bd7939f610d957afacaf6a131e75ed
>
> [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0b811db2cb2aabc910e53d34ebb95a15997c33e7
>
> Signed-off-by: Stephen Smalley <stephen.smalley.work@gmail.com>
> ---
> v2 adds kernel commit info to the description and man page and uses
> the suggested text from Simon McVittie for the description of
> the security context string in a module-neutral way.
>
> man7/socket.7 | 5 +++++
> man7/unix.7 | 46 ++++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 51 insertions(+)
>
> diff --git a/man7/socket.7 b/man7/socket.7
> index 21e891791..c3635f95b 100644
> --- a/man7/socket.7
> +++ b/man7/socket.7
> @@ -690,6 +690,11 @@ Return the credentials of the peer process connected to this socket.
> For further details, see
> .BR unix (7).
> .TP
> +.BR SO_PEERSEC " (since Linux 2.6.2)"
> +Return the security context of the peer socket connected to this socket.
> +For further details, see
> +.BR unix (7).
> +.TP
> .B SO_PRIORITY
> Set the protocol-defined priority for all packets to be sent on
> this socket.
> diff --git a/man7/unix.7 b/man7/unix.7
> index 50828a5bc..298521d4a 100644
> --- a/man7/unix.7
> +++ b/man7/unix.7
> @@ -349,6 +349,52 @@ stream sockets and for
> .B AF_UNIX
> stream and datagram socket pairs created using
> .BR socketpair (2).
> +.TP
> +.B SO_PEERSEC
> +This read-only socket option returns the
> +security context of the peer socket connected to this socket.
> +By default, this will be the same as the security context of
> +the process that created the peer socket unless overridden
> +by the policy or by a process with the required permissions.
> +.IP
> +The argument to
> +.BR getsockopt (2)
> +is a pointer to a
> +buffer of the specified length in bytes
> +into which the security context string will be copied.
> +If the buffer length is less than the length of the security
> +context string, then
> +.BR getsockopt (2)
> +will return the required length
> +via
> +.I optlen
> +and return \-1 and sets
> +.I errno
> +to
> +.BR ERANGE .
> +The caller should allocate at least
> +.BR NAME_MAX
> +bytes for the buffer initially although this is not guaranteed
> +to be sufficient. Resizing the buffer to the returned length
> +and retrying may be necessary.
> +.IP
> +The security context string may include a terminating null character
> +in the returned length, but is not guaranteed to do so: a security
> +context "foo" might be represented as either {'f','o','o'} of length 3
> +or {'f','o','o','\\0'} of length 4, which are considered to be
> +interchangeable. It is printable, does not contain non-terminating
> +null characters, and is in an unspecified encoding (in particular it
> +is not guaranteed to be ASCII or UTF-8).
> +.IP
> +The use of this option for sockets in the
> +.B AF_UNIX
> +address family
> +is supported since Linux 2.6.2 for connected stream sockets and
> +since Linux 4.18,
> +.\" commit 0b811db2cb2aabc910e53d34ebb95a15997c33e7
> +also for stream and datagram socket pairs created
> +using
> +.BR socketpair (2).
> .\"
> .SS Autobind feature
> If a
> --
> 2.25.1
>
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
^ permalink raw reply
* Re: [RFC PATCH 5/6] security/fbfam: Detect a fork brute force attack
From: Jann Horn @ 2020-09-14 19:42 UTC (permalink / raw)
To: John Wood
Cc: Kees Cook, Kernel Hardening, Matthew Wilcox, Jonathan Corbet,
Alexander Viro, Ingo Molnar, Peter Zijlstra, Juri Lelli,
Vincent Guittot, Dietmar Eggemann, Steven Rostedt, Ben Segall,
Mel Gorman, Luis Chamberlain, Iurii Zaikin, James Morris,
Serge E. Hallyn, linux-doc, kernel list, linux-fsdevel,
linux-security-module
In-Reply-To: <20200913172415.GA2880@ubuntu>
On Sun, Sep 13, 2020 at 7:55 PM John Wood <john.wood@gmx.com> wrote:
> On Thu, Sep 10, 2020 at 11:10:38PM +0200, Jann Horn wrote:
> > On Thu, Sep 10, 2020 at 10:22 PM Kees Cook <keescook@chromium.org> wrote:
> > > To detect a fork brute force attack it is necessary to compute the
> > > crashing rate of the application. This calculation is performed in each
> > > fatal fail of a task, or in other words, when a core dump is triggered.
> > > If this rate shows that the application is crashing quickly, there is a
> > > clear signal that an attack is happening.
> > >
> > > Since the crashing rate is computed in milliseconds per fault, if this
> > > rate goes under a certain threshold a warning is triggered.
[...]
> > > + delta_jiffies = get_jiffies_64() - stats->jiffies;
> > > + delta_time = jiffies64_to_msecs(delta_jiffies);
> > > + crashing_rate = delta_time / (u64)stats->faults;
> >
> > Do I see this correctly, is this computing the total runtime of this
> > process hierarchy divided by the total number of faults seen in this
> > process hierarchy? If so, you may want to reconsider whether that's
> > really the behavior you want. For example, if I configure the minimum
> > period between crashes to be 30s (as is the default in the sysctl
> > patch), and I try to attack a server that has been running without any
> > crashes for a month, I'd instantly be able to crash around
> > 30*24*60*60/30 = 86400 times before the detection kicks in. That seems
> > suboptimal.
>
> You are right. This is not the behaviour we want. So, for the next
> version it would be better to compute the crashing period as the time
> between two faults, or the time between the execve call and the first
> fault (first fault case).
>
> However, I am afraid of a premature detection if a child process fails
> twice in a short period.
>
> So, I think it would be a good idea add a new sysctl to setup a
> minimum number of faults before the time between faults starts to be
> computed. And so, the attack detection only will be triggered if the
> application crashes quickly but after a number of crashes.
>
> What do you think?
You could keep a list of the timestamps of the last five crashes or
so, and then take action if the last five crashes happened within
(5-1)*crash_period_limit time.
^ permalink raw reply
* Re: [RFC PATCH 5/6] security/fbfam: Detect a fork brute force attack
From: Jann Horn @ 2020-09-14 19:39 UTC (permalink / raw)
To: John Wood
Cc: Kees Cook, Kernel Hardening, Matthew Wilcox, Jonathan Corbet,
Alexander Viro, Ingo Molnar, Peter Zijlstra, Juri Lelli,
Vincent Guittot, Dietmar Eggemann, Steven Rostedt, Ben Segall,
Mel Gorman, Luis Chamberlain, Iurii Zaikin, James Morris,
Serge E. Hallyn, linux-doc, kernel list, linux-fsdevel,
linux-security-module
In-Reply-To: <20200913152724.GB2873@ubuntu>
On Sun, Sep 13, 2020 at 6:56 PM John Wood <john.wood@gmx.com> wrote:
> On Fri, Sep 11, 2020 at 02:01:56AM +0200, Jann Horn wrote:
> > On Fri, Sep 11, 2020 at 1:49 AM Kees Cook <keescook@chromium.org> wrote:
> > > On Thu, Sep 10, 2020 at 01:21:06PM -0700, Kees Cook wrote:
> > > > diff --git a/fs/coredump.c b/fs/coredump.c
> > > > index 76e7c10edfc0..d4ba4e1828d5 100644
> > > > --- a/fs/coredump.c
> > > > +++ b/fs/coredump.c
> > > > @@ -51,6 +51,7 @@
> > > > #include "internal.h"
> > > >
> > > > #include <trace/events/sched.h>
> > > > +#include <fbfam/fbfam.h>
> > > >
> > > > int core_uses_pid;
> > > > unsigned int core_pipe_limit;
> > > > @@ -825,6 +826,7 @@ void do_coredump(const kernel_siginfo_t *siginfo)
> > > > fail_creds:
> > > > put_cred(cred);
> > > > fail:
> > > > + fbfam_handle_attack(siginfo->si_signo);
> > >
> > > I don't think this is the right place for detecting a crash -- isn't
> > > this only for the "dumping core" condition? In other words, don't you
> > > want to do this in get_signal()'s "fatal" block? (i.e. very close to the
> > > do_coredump, but without the "should I dump?" check?)
> > >
> > > Hmm, but maybe I'm wrong? It looks like you're looking at noticing the
> > > process taking a signal from SIG_KERNEL_COREDUMP_MASK ?
> > >
> > > (Better yet: what are fatal conditions that do NOT match
> > > SIG_KERNEL_COREDUMP_MASK, and should those be covered?)
> > >
> > > Regardless, *this* looks like the only place without an LSM hook. And it
> > > doesn't seem unreasonable to add one here. I assume it would probably
> > > just take the siginfo pointer, which is also what you're checking.
> >
> > Good point, making this an LSM might be a good idea.
> >
> > > e.g. for include/linux/lsm_hook_defs.h:
> > >
> > > LSM_HOOK(int, 0, task_coredump, const kernel_siginfo_t *siginfo);
> >
> > I guess it should probably be an LSM_RET_VOID hook? And since, as you
> > said, it's not really semantically about core dumping, maybe it should
> > be named task_fatal_signal or something like that.
>
> If I understand correctly you propose to add a new LSM hook without return
> value and place it here:
>
> diff --git a/kernel/signal.c b/kernel/signal.c
> index a38b3edc6851..074492d23e98 100644
> --- a/kernel/signal.c
> +++ b/kernel/signal.c
> @@ -2751,6 +2751,8 @@ bool get_signal(struct ksignal *ksig)
> do_coredump(&ksig->info);
> }
>
> + // Add the new LSM hook here
> +
> /*
> * Death signals, no core dump.
> */
It should probably be in the "if (sig_kernel_coredump(signr)) {"
branch. And I'm not sure whether it should be before or after
do_coredump() - if you do it after do_coredump(), the hook will have
to wait until the core dump file has been written, which may take a
little bit of time.
^ permalink raw reply
* [PATCH v2] socket.7,unix.7: add initial description for SO_PEERSEC
From: Stephen Smalley @ 2020-09-14 18:07 UTC (permalink / raw)
To: mtk.manpages
Cc: linux-man, linux-security-module, selinux, smcv, jmorris, serge,
Stephen Smalley
SO_PEERSEC was introduced for AF_UNIX stream sockets connected via
connect(2) in Linux 2.6.2 [1] and later augmented to support AF_UNIX stream
and datagram sockets created via socketpair(2) in Linux 4.18 [2]. Document
SO_PEERSEC in the socket.7 and unix.7 man pages following the example
of the existing SO_PEERCRED descriptions. SO_PEERSEC is also supported
on AF_INET sockets when using labeled IPSEC or NetLabel but defer
adding a description of that support to a separate patch.
The module-independent description of the security context returned
by SO_PEERSEC is from Simon McVittie <smcv@collabora.com>.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/commit/?id=da6e57a2e6bd7939f610d957afacaf6a131e75ed
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0b811db2cb2aabc910e53d34ebb95a15997c33e7
Signed-off-by: Stephen Smalley <stephen.smalley.work@gmail.com>
---
v2 adds kernel commit info to the description and man page and uses
the suggested text from Simon McVittie for the description of
the security context string in a module-neutral way.
man7/socket.7 | 5 +++++
man7/unix.7 | 46 ++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 51 insertions(+)
diff --git a/man7/socket.7 b/man7/socket.7
index 21e891791..c3635f95b 100644
--- a/man7/socket.7
+++ b/man7/socket.7
@@ -690,6 +690,11 @@ Return the credentials of the peer process connected to this socket.
For further details, see
.BR unix (7).
.TP
+.BR SO_PEERSEC " (since Linux 2.6.2)"
+Return the security context of the peer socket connected to this socket.
+For further details, see
+.BR unix (7).
+.TP
.B SO_PRIORITY
Set the protocol-defined priority for all packets to be sent on
this socket.
diff --git a/man7/unix.7 b/man7/unix.7
index 50828a5bc..298521d4a 100644
--- a/man7/unix.7
+++ b/man7/unix.7
@@ -349,6 +349,52 @@ stream sockets and for
.B AF_UNIX
stream and datagram socket pairs created using
.BR socketpair (2).
+.TP
+.B SO_PEERSEC
+This read-only socket option returns the
+security context of the peer socket connected to this socket.
+By default, this will be the same as the security context of
+the process that created the peer socket unless overridden
+by the policy or by a process with the required permissions.
+.IP
+The argument to
+.BR getsockopt (2)
+is a pointer to a
+buffer of the specified length in bytes
+into which the security context string will be copied.
+If the buffer length is less than the length of the security
+context string, then
+.BR getsockopt (2)
+will return the required length
+via
+.I optlen
+and return \-1 and sets
+.I errno
+to
+.BR ERANGE .
+The caller should allocate at least
+.BR NAME_MAX
+bytes for the buffer initially although this is not guaranteed
+to be sufficient. Resizing the buffer to the returned length
+and retrying may be necessary.
+.IP
+The security context string may include a terminating null character
+in the returned length, but is not guaranteed to do so: a security
+context "foo" might be represented as either {'f','o','o'} of length 3
+or {'f','o','o','\\0'} of length 4, which are considered to be
+interchangeable. It is printable, does not contain non-terminating
+null characters, and is in an unspecified encoding (in particular it
+is not guaranteed to be ASCII or UTF-8).
+.IP
+The use of this option for sockets in the
+.B AF_UNIX
+address family
+is supported since Linux 2.6.2 for connected stream sockets and
+since Linux 4.18,
+.\" commit 0b811db2cb2aabc910e53d34ebb95a15997c33e7
+also for stream and datagram socket pairs created
+using
+.BR socketpair (2).
.\"
.SS Autobind feature
If a
--
2.25.1
^ permalink raw reply related
* Re: [PATCH] security: keys: Use kvfree_sensitive in a few places
From: Jarkko Sakkinen @ 2020-09-14 18:05 UTC (permalink / raw)
To: Denis Efremov, David Howells
Cc: Alex Dewar, David Howells, James Morris, Serge E. Hallyn,
keyrings, linux-security-module, linux-kernel
In-Reply-To: <f97076d2-de8a-4600-ee81-4cf4fcdc3ec1@linux.com>
On Fri, Sep 11, 2020 at 07:05:16PM +0300, Denis Efremov wrote:
> Hi,
>
> same patch
>
> https://lkml.org/lkml/2020/8/27/168
>
> Thanks,
> Denis
David, can you pick this up?
/Jarkko
^ permalink raw reply
* Re: [PATCH v2] certs: Add EFI_CERT_X509_GUID support for dbx entries
From: Jarkko Sakkinen @ 2020-09-14 18:02 UTC (permalink / raw)
To: Eric Snowberg
Cc: dhowells, dwmw2, herbert, davem, jmorris, serge, nayna, zohar,
erichte, mpe, keyrings, linux-kernel, linux-crypto,
linux-security-module
In-Reply-To: <20200914180127.GA9369@linux.intel.com>
On Mon, Sep 14, 2020 at 09:01:34PM +0300, Jarkko Sakkinen wrote:
> On Wed, Sep 09, 2020 at 01:27:36PM -0400, Eric Snowberg wrote:
> > The Secure Boot Forbidden Signature Database, dbx, contains a list of now
> > revoked signatures and keys previously approved to boot with UEFI Secure
> > Boot enabled. The dbx is capable of containing any number of
> > EFI_CERT_X509_SHA256_GUID, EFI_CERT_SHA256_GUID, and EFI_CERT_X509_GUID
> > entries.
> >
> > Currently when EFI_CERT_X509_GUID are contained in the dbx, the entries are
> > skipped.
> >
> > Add support for EFI_CERT_X509_GUID dbx entries. When a EFI_CERT_X509_GUID
> > is found, it is added as an asymmetrical key to the .blacklist keyring.
> > Anytime the .platform keyring is used, the keys in the .blacklist keyring
> > are referenced, if a matching key is found, the key will be rejected.
> >
> > Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
> > ---
> >
> > v2:
> > Fixed build issue reported by kernel test robot <lkp@intel.com>
> > Commit message update (suggested by Jarkko Sakkinen)
> >
> > ---
> > certs/blacklist.c | 36 +++++++++++++++++++
> > certs/system_keyring.c | 6 ++++
> > include/crypto/pkcs7.h | 8 +++++
> > include/keys/system_keyring.h | 11 ++++++
> > .../platform_certs/keyring_handler.c | 11 ++++++
> > 5 files changed, 72 insertions(+)
> >
> > diff --git a/certs/blacklist.c b/certs/blacklist.c
> > index 6514f9ebc943..17ebf50cf0ae 100644
> > --- a/certs/blacklist.c
> > +++ b/certs/blacklist.c
> > @@ -15,6 +15,7 @@
> > #include <linux/err.h>
> > #include <linux/seq_file.h>
> > #include <keys/system_keyring.h>
> > +#include <crypto/pkcs7.h>
> > #include "blacklist.h"
> >
> > static struct key *blacklist_keyring;
> > @@ -100,6 +101,41 @@ int mark_hash_blacklisted(const char *hash)
> > return 0;
> > }
> >
> > +int mark_key_revocationlisted(const char *data, size_t size)
> > +{
> > + key_ref_t key;
> > +
> > + key = key_create_or_update(make_key_ref(blacklist_keyring, true),
> > + "asymmetric",
> > + NULL,
> > + data,
> > + size,
> > + ((KEY_POS_ALL & ~KEY_POS_SETATTR) |
> > + KEY_USR_VIEW),
> > + KEY_ALLOC_NOT_IN_QUOTA |
> > + KEY_ALLOC_BUILT_IN);
> > +
> > + if (IS_ERR(key)) {
> > + pr_err("Problem with revocation key (%ld)\n", PTR_ERR(key));
> > + return PTR_ERR(key);
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +int is_key_revocationlisted(struct pkcs7_message *pkcs7)
> > +{
> > + int ret;
> > +
> > + ret = pkcs7_validate_trust(pkcs7, blacklist_keyring);
> > +
> > + if (ret == 0)
> > + return -EKEYREJECTED;
> > +
> > + return -ENOKEY;
> > +}
> > +EXPORT_SYMBOL_GPL(is_key_revocationlisted);
>
> What required this callable from a module?
Right, nees to be exported for pkcs7.
/Jarkko
^ permalink raw reply
* RE: [RFC PATCH 00/30] ima: Introduce IMA namespace
From: Krzysztof Struczynski @ 2020-09-14 12:05 UTC (permalink / raw)
To: Mimi Zohar, James Bottomley, linux-integrity@vger.kernel.org,
linux-kernel@vger.kernel.org,
containers@lists.linux-foundation.org,
linux-security-module@vger.kernel.org
Cc: stefanb@linux.vnet.ibm.com, sunyuqiong1988@gmail.com,
mkayaalp@cs.binghamton.edu, dmitry.kasatkin@gmail.com,
serge@hallyn.com, jmorris@namei.org, christian@brauner.io,
Silviu Vlasceanu, Roberto Sassu
In-Reply-To: <5331e60b5a1afb55e2bc778db1b95998466b687d.camel@linux.ibm.com>
> From: Mimi Zohar [mailto:zohar@linux.ibm.com]
> Sent: Wednesday, September 2, 2020 8:53 PM
> > > So I think this can work in the use case where the system owner is
> > > responsible for doing the logging and attestation and the tenants just
> > > trust the owner without requiring an attestation. However, in a multi-
> > > tenant system you need a way for the attestation to be per-container
> > > (because the combined list of who executed what would be a security
> > > leak between tenants). Since we can't virtualise the PCRs without
> > > introducing a vtpm this is going to require a vtpm infrastructure like
> > > that used for virtual machines and then we can do IMA logging per
> > > container.
> >
> > I agree and wonder if we should decouple the attestation trust model,
> > which depends on the specific use case (e.g. multi/single tenant,
> > public/private cloud), from the IMA logic of linking the measurements to
> > the container. Indeed, attestation from within the container might require
> > anchoring to a vTPM/vPCR and the current measurement tagging mechanism
> can
> > support several ways of anchoring them to a (virtual) root of trust.
> >
> > > I don't think the above has to be in your first patch set, we just have
> > > to have an idea of how it could be done to show that nothing in this
> > > patch set precludes a follow on from doing this.
> >
> > Given that virtualizing trust anchors seems like a separate problem in
> > which industry consensus is not easy to reach for all use cases, an
> > anchoring mechanism should probably be a separate IMA feature.
>
> Other trust anchors for "trusted keys" has been discussed, but I wasn't
> aware of any discussion about other trust anchors for the IMA
> measurement list. The IMA measurement list is very much tied to a TPM.
>
Agreed. I wouldn't consider anything else than the TPM in the IMA
measurement list context. The anchoring mechanism mentioned above
pertained to the possible extensions of the TPM anchor in the
containerized environment, like the vTPM.
> Including container measurements in the host measurement list, will
> unnecessarily cause the host measurement list to grow. The decision of
> what should and shouldn't be included in the host measurement list
> shouldn't be defined by the container.
>
The container has no impact on the measurement list entries other than the
ones related to the processes running within the container. This in turn,
the same as for the original IMA, is defined by the (container's) policy,
loaded on the container's creation.
Best regards,
Krzysztof
> Mimi
>
>
^ permalink raw reply
* RE: [RFC PATCH 00/30] ima: Introduce IMA namespace
From: Krzysztof Struczynski @ 2020-09-14 12:07 UTC (permalink / raw)
To: Mimi Zohar, Luke Hinds, Dr. Greg
Cc: Christian Brauner, linux-integrity@vger.kernel.org,
Linux Kernel Mailing List, containers@lists.linux-foundation.org,
linux-security-module@vger.kernel.org, stefanb@linux.vnet.ibm.com,
sunyuqiong1988@gmail.com, mkayaalp@cs.binghamton.edu,
dmitry.kasatkin@gmail.com, Serge E. Hallyn, James Morris,
christian@brauner.io, Silviu Vlasceanu, Roberto Sassu,
ebiederm@xmission.com, viro@zeniv.linux.org.uk,
torvalds@linux-foundation.org, luto@amacapital.net,
jannh@google.com, nick.dusek@gmail.com
In-Reply-To: <d405bab0d262b32fd16e85444791b6c49d820aa2.camel@linux.ibm.com>
> From: Mimi Zohar [mailto:zohar@linux.ibm.com]
> Sent: Tuesday, September 8, 2020 4:03 PM
> > > Candidly, given the politics of security technology being viewed as
> > > 'constraining' user rights, I think that a lot of forthcoming security
> > > technology may end up being out of tree moving forward.
> > >
> >
> > I think it's prudent to look forward and plan diligently, but I would
> > not want perfect to be the enemy of good.
>
> Agreed. This isn't an abstract problem, but one that has already come
> up and, hopefully, has been addressed appropriately.
>
> >
> > I approach this more from a user's perspective. We are using IMA in
> > https://keylime.dev to measure a host and would like to measure
> > within a container too. It's the most common request we hear from our
> > users.
> >
> > Perhaps we all collaborate on a proposal extending Stefans work here:
> > https://kernsec.org/wiki/index.php/IMA_Namespacing_design_considerati
> > ons
> >
> > I have seen around 3-4 patches now get submitted, so work has been
> > done before, and as above, users are present too. We could then have
> > some consensus on how this should look and later patches might have
> > more success at landing.
> >
> > Would anyone be interested in this and have recommendations on how we
> > could approach this?
>
> When Roberto Sassu and Krzysztof Struczynski contacted me about the
> status of Stefan Berger's patch set, based on Yuqiong Sun's work, I was
> under the impression that they would be rebasing it on the latest
> kernel and going forward from there. Obviously things changed. I
> pointed out to them resolving the "IMA namespacing" issue would be the
> first thing that needs to be addressed. So here we are.
>
The concept of the IMA namespace as a separate namespace, not attached to
the user or mount namespace, remains the same as in the last set of
Stefan's patches. The creation and configuration mechanism changed,
partially because of the changes in the upstream kernel like extension of
the CLONE_ flags, that facilitated other solutions. The main inspiration
in this regard was the new time namespace.
The implemented mechanism is intended to make the configuration of the IMA
namespace as similar as possible to the upstream IMA implementation and
allows to configure the new IMA namespace before any process enters that
namespace, so the very first actions can be measured/appraised/audited.
In this implementation many design points formulated by Stefan still stand.
The significant difference in the presented design is the threat model.
The actions of the host's root and any other user within the container are
measured/appraised/audited according to the container's policy. However,
every action that affects objects in the root namespace, is detected when
processes from the root namespace access them.
Best regards,
Krzysztof
> Definitely, let's have this discussion.
>
> Mimi
^ permalink raw reply
* Re: [RFC PATCH v9 0/3] Add introspect_access(2) (was O_MAYEXEC)
From: Mickaël Salaün @ 2020-09-14 16:43 UTC (permalink / raw)
To: Arnd Bergmann, Michael Kerrisk, linux-api
Cc: James Morris, Matthew Wilcox, Mimi Zohar, linux-kernel,
Aleksa Sarai, Alexei Starovoitov, Al Viro, Andrew Morton,
Andy Lutomirski, Casey Schaufler, Christian Brauner,
Christian Heimes, Daniel Borkmann, Deven Bowers, Dmitry Vyukov,
Eric Biggers, Eric Chiang, Florian Weimer, Jan Kara, Jann Horn,
Jonathan Corbet, Kees Cook, Lakshmi Ramasubramanian,
Matthew Garrett, Miklos Szeredi, Philippe Trébuchet,
Scott Shell, Sean Christopherson, Shuah Khan, Steve Dower,
Steve Grubb, Tetsuo Handa, Thibaut Sautereau, Vincent Strubel,
kernel-hardening, linux-integrity, linux-security-module,
linux-fsdevel
In-Reply-To: <alpine.LRH.2.21.2009121019050.17638@namei.org>
Arnd and Michael,
What do you think of "should_faccessat" or "entrusted_faccessat" for
this new system call?
On 12/09/2020 02:28, James Morris wrote:
> On Thu, 10 Sep 2020, Matthew Wilcox wrote:
>
>> On Thu, Sep 10, 2020 at 08:38:21PM +0200, Mickaël Salaün wrote:
>>> There is also the use case of noexec mounts and file permissions. From
>>> user space point of view, it doesn't matter which kernel component is in
>>> charge of defining the policy. The syscall should then not be tied with
>>> a verification/integrity/signature/appraisal vocabulary, but simply an
>>> access control one.
>>
>> permission()?
>>
>
> The caller is not asking the kernel to grant permission, it's asking
> "SHOULD I access this file?"
>
> The caller doesn't know, for example, if the script file it's about to
> execute has been signed, or if it's from a noexec mount. It's asking the
> kernel, which does know. (Note that this could also be extended to reading
> configuration files).
>
> How about: should_faccessat ?
>
Sounds good to me.
^ permalink raw reply
* kernel BUG at lib/assoc_array.c:LINE! (2)
From: syzbot @ 2020-09-14 9:29 UTC (permalink / raw)
To: dhowells, jarkko.sakkinen, jmorris, keyrings, linux-kernel,
linux-security-module, serge, syzkaller-bugs
Hello,
syzbot found the following issue on:
HEAD commit: e8878ab8 Merge tag 'spi-fix-v5.9-rc4' of git://git.kernel...
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=12892c11900000
kernel config: https://syzkaller.appspot.com/x/.config?x=c61610091f4ca8c4
dashboard link: https://syzkaller.appspot.com/bug?extid=5cb98ddf89ec01d73c6d
compiler: gcc (GCC) 10.1.0-syz 20200507
Unfortunately, I don't have any reproducer for this issue yet.
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+5cb98ddf89ec01d73c6d@syzkaller.appspotmail.com
------------[ cut here ]------------
kernel BUG at lib/assoc_array.c:652!
invalid opcode: 0000 [#1] PREEMPT SMP KASAN
CPU: 1 PID: 7123 Comm: kworker/1:3 Not tainted 5.9.0-rc4-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Workqueue: afs afs_manage_cell
RIP: 0010:assoc_array_insert_into_terminal_node lib/assoc_array.c:652 [inline]
RIP: 0010:assoc_array_insert+0x1cbe/0x2a80 lib/assoc_array.c:1001
Code: 0f 84 cd fe ff ff e8 e1 62 15 fe e9 c3 fe ff ff e8 57 5c d5 fd 0f 0b e8 50 5c d5 fd 0f 0b e8 49 5c d5 fd 0f 0b e8 42 5c d5 fd <0f> 0b 48 8b 04 24 4c 89 74 24 70 48 b9 00 00 00 00 00 fc ff df 41
RSP: 0018:ffffc900054977a0 EFLAGS: 00010293
RAX: 0000000000000000 RBX: 000000000000000f RCX: ffffffff839eeb4c
RDX: ffff8880553a0540 RSI: ffffffff839ef13e RDI: ffff88804726f688
RBP: 0000000000000011 R08: 0000000000000dc0 R09: ffffffff8b177750
R10: 0000000000000010 R11: 000000000000016e R12: 0000000000000010
R13: ffff888053910000 R14: ffff888051e50101 R15: 0000000000000001
FS: 0000000000000000(0000) GS:ffff8880ae700000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000768000 CR3: 000000009e098000 CR4: 00000000001506e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
__key_link_begin+0xec/0x250 security/keys/keyring.c:1314
construct_alloc_key security/keys/request_key.c:404 [inline]
construct_key_and_link security/keys/request_key.c:499 [inline]
request_key_and_link+0x894/0x1350 security/keys/request_key.c:637
request_key_tag+0x4e/0xb0 security/keys/request_key.c:701
dns_query+0x257/0x6c3 net/dns_resolver/dns_query.c:128
afs_dns_query+0x122/0x390 fs/afs/addr_list.c:249
afs_update_cell fs/afs/cell.c:403 [inline]
afs_manage_cell+0x8c5/0x11c0 fs/afs/cell.c:708
process_one_work+0x94c/0x1670 kernel/workqueue.c:2269
worker_thread+0x64c/0x1120 kernel/workqueue.c:2415
kthread+0x3b5/0x4a0 kernel/kthread.c:292
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294
Modules linked in:
---[ end trace 234f5667657c5700 ]---
RIP: 0010:assoc_array_insert_into_terminal_node lib/assoc_array.c:652 [inline]
RIP: 0010:assoc_array_insert+0x1cbe/0x2a80 lib/assoc_array.c:1001
Code: 0f 84 cd fe ff ff e8 e1 62 15 fe e9 c3 fe ff ff e8 57 5c d5 fd 0f 0b e8 50 5c d5 fd 0f 0b e8 49 5c d5 fd 0f 0b e8 42 5c d5 fd <0f> 0b 48 8b 04 24 4c 89 74 24 70 48 b9 00 00 00 00 00 fc ff df 41
RSP: 0018:ffffc900054977a0 EFLAGS: 00010293
RAX: 0000000000000000 RBX: 000000000000000f RCX: ffffffff839eeb4c
RDX: ffff8880553a0540 RSI: ffffffff839ef13e RDI: ffff88804726f688
RBP: 0000000000000011 R08: 0000000000000dc0 R09: ffffffff8b177750
R10: 0000000000000010 R11: 000000000000016e R12: 0000000000000010
R13: ffff888053910000 R14: ffff888051e50101 R15: 0000000000000001
FS: 0000000000000000(0000) GS:ffff8880ae700000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f340d222000 CR3: 00000000a6f13000 CR4: 00000000001506e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
^ permalink raw reply
* Re: [PATCH v6 0/8] crpyto: introduce OSCCA certificate and SM2 asymmetric algorithm
From: Tianjia Zhang @ 2020-09-14 7:04 UTC (permalink / raw)
To: Herbert Xu
Cc: David S. Miller, David Howells, Maxime Coquelin, Alexandre Torgue,
James Morris, Serge E. Hallyn, Stephan Mueller,
Marcelo Henrique Cerri, Steven Rostedt (VMware), Masahiro Yamada,
Brendan Higgins, Andrew Morton, Johannes Weiner, Waiman Long,
Mimi Zohar, Lakshmi Ramasubramanian, Colin Ian King,
Tushar Sugandhi, Vitaly Chikunov, Gilad Ben-Yossef,
Pascal van Leeuwen, linux-crypto, linux-kernel, keyrings,
linux-stm32, linux-arm-kernel, linux-security-module,
Xufeng Zhang, Jia Zhang
In-Reply-To: <20200911042442.GA5420@gondor.apana.org.au>
Hi，
On 9/11/20 12:24 PM, Herbert Xu wrote:
> On Thu, Sep 03, 2020 at 09:12:34PM +0800, Tianjia Zhang wrote:
>>
>> ---
>> v6 changes:
>> 1. remove mpi_sub_ui function from mpi library.
>> 2. rebase on mainline.
>
> This series is still missing acks for patches 6-8. Without them
> it cannot proceed.
>
> Thanks,
>
This series has some review suggestions for patches 6-8, but the
maintainer of asymmetric keys David Howells <dhowells@redhat.com>, I
can’t get in touch. The email has been sent successfully. Can you help
ping him ?
Thanks and best,
Tianjia
^ permalink raw reply
* Re: [PATCH v6 7/8] X.509: support OSCCA sm2-with-sm3 certificate verification
From: Tianjia Zhang @ 2020-09-14 6:34 UTC (permalink / raw)
To: Gilad Ben-Yossef
Cc: Herbert Xu, David S. Miller, David Howells, Maxime Coquelin,
Alexandre Torgue, James Morris, Serge E. Hallyn, Stephan Mueller,
Marcelo Henrique Cerri, Steven Rostedt (VMware), Masahiro Yamada,
Brendan Higgins, Andrew Morton, Johannes Weiner, Waiman Long,
Mimi Zohar, Lakshmi Ramasubramanian, Colin Ian King,
Tushar Sugandhi, Vitaly Chikunov, Pascal van Leeuwen,
Linux Crypto Mailing List, Linux kernel mailing list, keyrings,
linux-stm32, Linux ARM, linux-security-module, Xufeng Zhang,
Jia Zhang
In-Reply-To: <CAOtvUMfT5zgv=e9nCgz8-1r7LuYSRZ8Zdx2xc0JwckUJZufcvg@mail.gmail.com>
Hi Gilad,
On 9/13/20 3:12 PM, Gilad Ben-Yossef wrote:
> Hi,
>
>
> On Thu, Sep 3, 2020 at 4:13 PM Tianjia Zhang
> <tianjia.zhang@linux.alibaba.com> wrote:
>>
>> The digital certificate format based on SM2 crypto algorithm as
>> specified in GM/T 0015-2012. It was published by State Encryption
>> Management Bureau, China.
>>
>> The method of generating Other User Information is defined as
>> ZA=H256(ENTLA || IDA || a || b || xG || yG || xA || yA), it also
>> specified in https://tools.ietf.org/html/draft-shen-sm2-ecdsa-02.
>>
>> The x509 certificate supports sm2-with-sm3 type certificate
>> verification. Because certificate verification requires ZA
>> in addition to tbs data, ZA also depends on elliptic curve
>> parameters and public key data, so you need to access tbs in sig
>> and calculate ZA. Finally calculate the digest of the
>> signature and complete the verification work. The calculation
>> process of ZA is declared in specifications GM/T 0009-2012
>> and GM/T 0003.2-2012.
>>
>> Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
>> Tested-by: Xufeng Zhang <yunbo.xufeng@linux.alibaba.com>
>> ---
>> crypto/asymmetric_keys/Makefile | 1 +
>> crypto/asymmetric_keys/public_key.c | 6 +++
>> crypto/asymmetric_keys/public_key_sm2.c | 61 ++++++++++++++++++++++++
>> crypto/asymmetric_keys/x509_public_key.c | 3 ++
>> include/crypto/public_key.h | 15 ++++++
>> 5 files changed, 86 insertions(+)
>> create mode 100644 crypto/asymmetric_keys/public_key_sm2.c
>>
>> diff --git a/crypto/asymmetric_keys/Makefile b/crypto/asymmetric_keys/Makefile
>> index 28b91adba2ae..1a99ea5acb6b 100644
>> --- a/crypto/asymmetric_keys/Makefile
>> +++ b/crypto/asymmetric_keys/Makefile
>> @@ -11,6 +11,7 @@ asymmetric_keys-y := \
>> signature.o
>>
>> obj-$(CONFIG_ASYMMETRIC_PUBLIC_KEY_SUBTYPE) += public_key.o
>> +obj-$(CONFIG_ASYMMETRIC_PUBLIC_KEY_SUBTYPE) += public_key_sm2.o
>> obj-$(CONFIG_ASYMMETRIC_TPM_KEY_SUBTYPE) += asym_tpm.o
>>
>> #
>> diff --git a/crypto/asymmetric_keys/public_key.c b/crypto/asymmetric_keys/public_key.c
>> index d8410ffd7f12..1d0492098bbd 100644
>> --- a/crypto/asymmetric_keys/public_key.c
>> +++ b/crypto/asymmetric_keys/public_key.c
>> @@ -299,6 +299,12 @@ int public_key_verify_signature(const struct public_key *pkey,
>> if (ret)
>> goto error_free_key;
>>
>> + if (strcmp(sig->pkey_algo, "sm2") == 0 && sig->data_size) {
>> + ret = cert_sig_digest_update(sig, tfm);
>> + if (ret)
>> + goto error_free_key;
>> + }
>> +
>> sg_init_table(src_sg, 2);
>> sg_set_buf(&src_sg[0], sig->s, sig->s_size);
>> sg_set_buf(&src_sg[1], sig->digest, sig->digest_size);
>> diff --git a/crypto/asymmetric_keys/public_key_sm2.c b/crypto/asymmetric_keys/public_key_sm2.c
>> new file mode 100644
>> index 000000000000..7325cf21dbb4
>> --- /dev/null
>> +++ b/crypto/asymmetric_keys/public_key_sm2.c
>> @@ -0,0 +1,61 @@
>> +/* SPDX-License-Identifier: GPL-2.0-or-later */
>> +/*
>> + * asymmetric public-key algorithm for SM2-with-SM3 certificate
>> + * as specified by OSCCA GM/T 0003.1-2012 -- 0003.5-2012 SM2 and
>> + * described at https://tools.ietf.org/html/draft-shen-sm2-ecdsa-02
>> + *
>> + * Copyright (c) 2020, Alibaba Group.
>> + * Authors: Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
>> + */
>> +
>> +#include <crypto/sm3_base.h>
>> +#include <crypto/sm2.h>
>> +#include <crypto/public_key.h>
>> +
>> +#if IS_REACHABLE(CONFIG_CRYPTO_SM2)
>> +
>> +int cert_sig_digest_update(const struct public_key_signature *sig,
>> + struct crypto_akcipher *tfm_pkey)
>> +{
>> + struct crypto_shash *tfm;
>> + struct shash_desc *desc;
>> + size_t desc_size;
>> + unsigned char dgst[SM3_DIGEST_SIZE];
>> + int ret;
>> +
>> + BUG_ON(!sig->data);
>> +
>> + ret = sm2_compute_z_digest(tfm_pkey, SM2_DEFAULT_USERID,
>> + SM2_DEFAULT_USERID_LEN, dgst);
>> + if (ret)
>> + return ret;
>> +
>> + tfm = crypto_alloc_shash(sig->hash_algo, 0, 0);
>> + if (IS_ERR(tfm))
>> + return PTR_ERR(tfm);
>> +
>> + desc_size = crypto_shash_descsize(tfm) + sizeof(*desc);
>> + desc = kzalloc(desc_size, GFP_KERNEL);
>> + if (!desc)
>> + goto error_free_tfm;
>> +
>> + desc->tfm = tfm;
>> +
>> + ret = crypto_shash_init(desc);
>> + if (ret < 0)
>> + goto error_free_desc;
>> +
>> + ret = crypto_shash_update(desc, dgst, SM3_DIGEST_SIZE);
>> + if (ret < 0)
>> + goto error_free_desc;
>> +
>> + ret = crypto_shash_finup(desc, sig->data, sig->data_size, sig->digest);
>
> It looks like you are doing a separate init, update, finup every time
> - I would consider using crypto_shash_digest() in one go.
>
> In fact, considering the fact that you are allocating a tfm just for
> this use and then releasing it, I would consider switching to
> crypto_shash_tfm_digest() and dropping the kzalloc all together.
>
> This should simplify the code a bit.
>
> Other than that I don't have anything smart to say :-)
>
> Gilad
>
The hash calculation here includes two parts of data, 'dgst' and
'sig->data'. The last call is 'finup()' not 'final()'. I understand that
it should not be possible to use 'crypto_shash_tfm_digest()' This kind
of function is simplified.
If a new scope is added, the assignment of desc can be optimized, as
follows:
```
do {
SHASH_DESC_ON_STACK(desc, tfm);
desc->tfm = tfm;
/* ... */
} while (0);
```
However, the kernel code may not accept this style. What is your opinion?
Thanks,
Tianjia
^ permalink raw reply
* [PATCH -next] dh key: convert to use be32_add_cpu()
From: Liu Shixin @ 2020-09-14 4:17 UTC (permalink / raw)
To: David Howells, Jarkko Sakkinen, James Morris
Cc: keyrings, linux-security-module, linux-kernel, Liu Shixin
Convert cpu_to_be32(be32_to_cpu(E1) + E2) to use be32_add_cpu().
Signed-off-by: Liu Shixin <liushixin2@huawei.com>
---
security/keys/dh.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/security/keys/dh.c b/security/keys/dh.c
index 1abfa70ed6e1..2635cb8a4561 100644
--- a/security/keys/dh.c
+++ b/security/keys/dh.c
@@ -186,7 +186,7 @@ static int kdf_ctr(struct kdf_sdesc *sdesc, const u8 *src, unsigned int slen,
dlen -= h;
dst += h;
- counter = cpu_to_be32(be32_to_cpu(counter) + 1);
+ be32_add_cpu(&counter, 1);
}
return 0;
--
2.25.1
^ permalink raw reply related
* Re: [RFC PATCH 5/6] security/fbfam: Detect a fork brute force attack
From: John Wood @ 2020-09-13 17:54 UTC (permalink / raw)
To: Jann Horn
Cc: Kees Cook, Kernel Hardening, John Wood, Matthew Wilcox,
Jonathan Corbet, Alexander Viro, Ingo Molnar, Peter Zijlstra,
Juri Lelli, Vincent Guittot, Dietmar Eggemann, Steven Rostedt,
Ben Segall, Mel Gorman, Luis Chamberlain, Iurii Zaikin,
James Morris, Serge E. Hallyn, linux-doc, kernel list,
linux-fsdevel, linux-security-module
In-Reply-To: <CAG48ez1gbu+eBA_PthLemcVVR+AU7Xa1zzbJ8tLMLBDCe_a+fQ@mail.gmail.com>
Hi,
On Thu, Sep 10, 2020 at 11:10:38PM +0200, Jann Horn wrote:
> On Thu, Sep 10, 2020 at 10:22 PM Kees Cook <keescook@chromium.org> wrote:
> > To detect a fork brute force attack it is necessary to compute the
> > crashing rate of the application. This calculation is performed in each
> > fatal fail of a task, or in other words, when a core dump is triggered.
> > If this rate shows that the application is crashing quickly, there is a
> > clear signal that an attack is happening.
> >
> > Since the crashing rate is computed in milliseconds per fault, if this
> > rate goes under a certain threshold a warning is triggered.
> [...]
> > +/**
> > + * fbfam_handle_attack() - Fork brute force attack detection.
> > + * @signal: Signal number that causes the core dump.
> > + *
> > + * The crashing rate of an application is computed in milliseconds per fault in
> > + * each crash. So, if this rate goes under a certain threshold there is a clear
> > + * signal that the application is crashing quickly. At this moment, a fork brute
> > + * force attack is happening.
> > + *
> > + * Return: -EFAULT if the current task doesn't have statistical data. Zero
> > + * otherwise.
> > + */
> > +int fbfam_handle_attack(int signal)
> > +{
> > + struct fbfam_stats *stats = current->fbfam_stats;
> > + u64 delta_jiffies, delta_time;
> > + u64 crashing_rate;
> > +
> > + if (!stats)
> > + return -EFAULT;
> > +
> > + if (!(signal == SIGILL || signal == SIGBUS || signal == SIGKILL ||
> > + signal == SIGSEGV || signal == SIGSYS))
> > + return 0;
>
> As far as I can tell, you can never get here with SIGKILL, since
> SIGKILL doesn't trigger core dumping and also isn't used by seccomp?
Understood.
> > +
> > + stats->faults += 1;
>
> This is a data race. If you want to be able to increment a variable
> that may be concurrently incremented by other tasks, use either
> locking or the atomic_t helpers.
Ok, I will correct this for the next version. Thanks.
> > + delta_jiffies = get_jiffies_64() - stats->jiffies;
> > + delta_time = jiffies64_to_msecs(delta_jiffies);
> > + crashing_rate = delta_time / (u64)stats->faults;
>
> Do I see this correctly, is this computing the total runtime of this
> process hierarchy divided by the total number of faults seen in this
> process hierarchy? If so, you may want to reconsider whether that's
> really the behavior you want. For example, if I configure the minimum
> period between crashes to be 30s (as is the default in the sysctl
> patch), and I try to attack a server that has been running without any
> crashes for a month, I'd instantly be able to crash around
> 30*24*60*60/30 = 86400 times before the detection kicks in. That seems
> suboptimal.
You are right. This is not the behaviour we want. So, for the next
version it would be better to compute the crashing period as the time
between two faults, or the time between the execve call and the first
fault (first fault case).
However, I am afraid of a premature detection if a child process fails
twice in a short period.
So, I think it would be a good idea add a new sysctl to setup a
minimum number of faults before the time between faults starts to be
computed. And so, the attack detection only will be triggered if the
application crashes quickly but after a number of crashes.
What do you think?
>
> (By the way, it kind of annoys me that you call it the "rate" when
> it's actually the inverse of the rate. "Period" might be more
> appropriate?)
Yes, "period" it's more appropiate. Thanks for the clarification.
> > + if (crashing_rate < (u64)sysctl_crashing_rate_threshold)
> > + pr_warn("fbfam: Fork brute force attack detected\n");
> > +
> > + return 0;
> > +}
> > +
> > --
> > 2.25.1
> >
Regards,
John Wood
^ permalink raw reply
* Re: [RFC PATCH 5/6] security/fbfam: Detect a fork brute force attack
From: John Wood @ 2020-09-13 16:56 UTC (permalink / raw)
To: Jann Horn, Kees Cook
Cc: Kernel Hardening, John Wood, Matthew Wilcox, Jonathan Corbet,
Alexander Viro, Ingo Molnar, Peter Zijlstra, Juri Lelli,
Vincent Guittot, Dietmar Eggemann, Steven Rostedt, Ben Segall,
Mel Gorman, Luis Chamberlain, Iurii Zaikin, James Morris,
Serge E. Hallyn, linux-doc, kernel list, linux-fsdevel,
linux-security-module
In-Reply-To: <CAG48ez2fP7yupg6Th+Hg0tL3o06p2PR1HtQcvy4Ro+Q5T2Nfkw@mail.gmail.com>
Hi,
On Fri, Sep 11, 2020 at 02:01:56AM +0200, Jann Horn wrote:
> On Fri, Sep 11, 2020 at 1:49 AM Kees Cook <keescook@chromium.org> wrote:
> > On Thu, Sep 10, 2020 at 01:21:06PM -0700, Kees Cook wrote:
> > > diff --git a/fs/coredump.c b/fs/coredump.c
> > > index 76e7c10edfc0..d4ba4e1828d5 100644
> > > --- a/fs/coredump.c
> > > +++ b/fs/coredump.c
> > > @@ -51,6 +51,7 @@
> > > #include "internal.h"
> > >
> > > #include <trace/events/sched.h>
> > > +#include <fbfam/fbfam.h>
> > >
> > > int core_uses_pid;
> > > unsigned int core_pipe_limit;
> > > @@ -825,6 +826,7 @@ void do_coredump(const kernel_siginfo_t *siginfo)
> > > fail_creds:
> > > put_cred(cred);
> > > fail:
> > > + fbfam_handle_attack(siginfo->si_signo);
> >
> > I don't think this is the right place for detecting a crash -- isn't
> > this only for the "dumping core" condition? In other words, don't you
> > want to do this in get_signal()'s "fatal" block? (i.e. very close to the
> > do_coredump, but without the "should I dump?" check?)
> >
> > Hmm, but maybe I'm wrong? It looks like you're looking at noticing the
> > process taking a signal from SIG_KERNEL_COREDUMP_MASK ?
> >
> > (Better yet: what are fatal conditions that do NOT match
> > SIG_KERNEL_COREDUMP_MASK, and should those be covered?)
> >
> > Regardless, *this* looks like the only place without an LSM hook. And it
> > doesn't seem unreasonable to add one here. I assume it would probably
> > just take the siginfo pointer, which is also what you're checking.
>
> Good point, making this an LSM might be a good idea.
>
> > e.g. for include/linux/lsm_hook_defs.h:
> >
> > LSM_HOOK(int, 0, task_coredump, const kernel_siginfo_t *siginfo);
>
> I guess it should probably be an LSM_RET_VOID hook? And since, as you
> said, it's not really semantically about core dumping, maybe it should
> be named task_fatal_signal or something like that.
If I understand correctly you propose to add a new LSM hook without return
value and place it here:
diff --git a/kernel/signal.c b/kernel/signal.c
index a38b3edc6851..074492d23e98 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -2751,6 +2751,8 @@ bool get_signal(struct ksignal *ksig)
do_coredump(&ksig->info);
}
+ // Add the new LSM hook here
+
/*
* Death signals, no core dump.
*/
Thanks,
John Wood
^ permalink raw reply related
* Re: [RFC PATCH 4/6] security/fbfam: Add a new sysctl to control the crashing rate threshold
From: John Wood @ 2020-09-13 14:33 UTC (permalink / raw)
To: Kees Cook
Cc: Jann Horn, kernel-hardening, John Wood, Matthew Wilcox,
Jonathan Corbet, Alexander Viro, Ingo Molnar, Peter Zijlstra,
Juri Lelli, Vincent Guittot, Dietmar Eggemann, Steven Rostedt,
Ben Segall, Mel Gorman, Luis Chamberlain, Iurii Zaikin,
James Morris, Serge E. Hallyn, linux-doc, linux-kernel,
linux-fsdevel, linux-security-module
In-Reply-To: <202009101612.18BAD0241D@keescook>
Hi, more inline.
On Thu, Sep 10, 2020 at 04:14:38PM -0700, Kees Cook wrote:
> > diff --git a/include/fbfam/fbfam.h b/include/fbfam/fbfam.h
> > index b5b7d1127a52..2cfe51d2b0d5 100644
> > --- a/include/fbfam/fbfam.h
> > +++ b/include/fbfam/fbfam.h
> > @@ -3,8 +3,12 @@
> > #define _FBFAM_H_
> >
> > #include <linux/sched.h>
> > +#include <linux/sysctl.h>
> >
> > #ifdef CONFIG_FBFAM
> > +#ifdef CONFIG_SYSCTL
> > +extern struct ctl_table fbfam_sysctls[];
> > +#endif
>
> Instead of doing the extern and adding to sysctl.c, this can all be done
> directly (dynamically) from the fbfam.c file instead.
Like Yama do in the yama_init_sysctl() function? As a reference code.
> > int fbfam_fork(struct task_struct *child);
> > int fbfam_execve(void);
> > int fbfam_exit(void);
> > diff --git a/kernel/sysctl.c b/kernel/sysctl.c
> > index 09e70ee2332e..c3b4d737bef3 100644
> > --- a/kernel/sysctl.c
> > +++ b/kernel/sysctl.c
> > @@ -77,6 +77,8 @@
> > #include <linux/uaccess.h>
> > #include <asm/processor.h>
> >
> > +#include <fbfam/fbfam.h>
> > +
> > #ifdef CONFIG_X86
> > #include <asm/nmi.h>
> > #include <asm/stacktrace.h>
> > @@ -2660,6 +2662,13 @@ static struct ctl_table kern_table[] = {
> > .extra1 = SYSCTL_ZERO,
> > .extra2 = SYSCTL_ONE,
> > },
> > +#endif
> > +#ifdef CONFIG_FBFAM
> > + {
> > + .procname = "fbfam",
> > + .mode = 0555,
> > + .child = fbfam_sysctls,
> > + },
> > #endif
> > { }
> > };
> > diff --git a/security/fbfam/Makefile b/security/fbfam/Makefile
> > index f4b9f0b19c44..b8d5751ecea4 100644
> > --- a/security/fbfam/Makefile
> > +++ b/security/fbfam/Makefile
> > @@ -1,2 +1,3 @@
> > # SPDX-License-Identifier: GPL-2.0
> > obj-$(CONFIG_FBFAM) += fbfam.o
> > +obj-$(CONFIG_SYSCTL) += sysctl.o
> > diff --git a/security/fbfam/fbfam.c b/security/fbfam/fbfam.c
> > index 0387f95f6408..9be4639b72eb 100644
> > --- a/security/fbfam/fbfam.c
> > +++ b/security/fbfam/fbfam.c
> > @@ -7,6 +7,17 @@
> > #include <linux/refcount.h>
> > #include <linux/slab.h>
> >
> > +/**
> > + * sysctl_crashing_rate_threshold - Crashing rate threshold.
> > + *
> > + * The rate's units are in milliseconds per fault.
> > + *
> > + * A fork brute force attack will be detected if the application's crashing rate
> > + * falls under this threshold. So, the higher this value, the faster an attack
> > + * will be detected.
> > + */
> > +unsigned long sysctl_crashing_rate_threshold = 30000;
>
> I would move the sysctls here, instead. (Also, the above should be
> const.)
If the above variable is const how the sysctl interface can modify it?
I think it would be better to declare it as __read_mostly instead. What
do you think?
unsigned long sysctl_crashing_rate_threshold __read_mostly = 30000;
> > +
> > /**
> > * struct fbfam_stats - Fork brute force attack mitigation statistics.
> > * @refc: Reference counter.
> > diff --git a/security/fbfam/sysctl.c b/security/fbfam/sysctl.c
> > new file mode 100644
> > index 000000000000..430323ad8e9f
> > --- /dev/null
> > +++ b/security/fbfam/sysctl.c
> > @@ -0,0 +1,20 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +#include <linux/sysctl.h>
> > +
> > +extern unsigned long sysctl_crashing_rate_threshold;
> > +static unsigned long ulong_one = 1;
> > +static unsigned long ulong_max = ULONG_MAX;
> > +
> > +struct ctl_table fbfam_sysctls[] = {
> > + {
> > + .procname = "crashing_rate_threshold",
> > + .data = &sysctl_crashing_rate_threshold,
> > + .maxlen = sizeof(sysctl_crashing_rate_threshold),
> > + .mode = 0644,
> > + .proc_handler = proc_doulongvec_minmax,
> > + .extra1 = &ulong_one,
> > + .extra2 = &ulong_max,
> > + },
> > + { }
> > +};
>
> I wouldn't bother splitting this into a separate file. (Just leave it in
> fbfam.c)
>
> --
> Kees Cook
Thanks,
John Wood
^ permalink raw reply
* Re: [RESEND][RFC PATCH 0/6] Fork brute force attack mitigation (fbfam)
From: John Wood @ 2020-09-13 7:24 UTC (permalink / raw)
To: Ondrej Mosnacek, Mel Gorman
Cc: John Wood, James Morris, Kees Cook, Kernel Hardening,
Matthew Wilcox, Jonathan Corbet, Alexander Viro, Ingo Molnar,
Peter Zijlstra, Juri Lelli, Vincent Guittot, Dietmar Eggemann,
Steven Rostedt, Ben Segall, Luis Chamberlain, Iurii Zaikin,
Serge E. Hallyn, linux-doc, Linux kernel mailing list,
linux-fsdevel, Linux Security Module list
In-Reply-To: <CAFqZXNtwDpX+O69Jj3AmxMoiW7o6SE07SqDDFnGMObu8hLDQDg@mail.gmail.com>
Hi,
On Sat, Sep 12, 2020 at 10:48:39PM +0200, Ondrej Mosnacek wrote:
> On Sat, Sep 12, 2020 at 4:51 PM Mel Gorman <mgorman@suse.de> wrote:
> > On Sat, Sep 12, 2020 at 11:36:52AM +0200, John Wood wrote:
> > > On Sat, Sep 12, 2020 at 12:56:18AM -0700, Kees Cook wrote:
> > > > On Sat, Sep 12, 2020 at 10:03:23AM +1000, James Morris wrote:
> > > > > On Thu, 10 Sep 2020, Kees Cook wrote:
> > > > >
> > > > > > [kees: re-sending this series on behalf of John Wood <john.wood@gmx.com>
> > > > > > also visible at https://github.com/johwood/linux fbfam]
> > > > > >
> > > > > > From: John Wood <john.wood@gmx.com>
> > > > >
> > > > > Why are you resending this? The author of the code needs to be able to
> > > > > send and receive emails directly as part of development and maintenance.
> > >
> > > I tried to send the full patch serie by myself but my email got blocked. After
> > > get support from my email provider it told to me that my account is young,
> > > and due to its spam policie I am not allow, for now, to send a big amount
> > > of mails in a short period. They also informed me that soon I will be able
> > > to send more mails. The quantity increase with the age of the account.
> > >
> >
> > If you're using "git send-email" then specify --confirm=always and
> > either manually send a mail every few seconds or use an expect script
> > like
> >
> > #!/bin/bash
> > EXPECT_SCRIPT=
> > function cleanup() {
> > if [ "$EXPECT_SCRIPT" != "" ]; then
> > rm $EXPECT_SCRIPT
> > fi
> > }
> > trap cleanup EXIT
> >
> > EXPECT_SCRIPT=`mktemp`
> > cat > $EXPECT_SCRIPT <<EOF
> > spawn sh ./SEND
> > expect {
> > "Send this email" { sleep 10; exp_send y\\r; exp_continue }
> > }
> > EOF
> >
> > expect -f $EXPECT_SCRIPT
> > exit $?
> >
> > This will work if your provider limits the rate mails are sent rather
> > than the total amount.
Yes, it seems to be what is happening.
> ...or you could keep it simple and just pass "--batch-size 1
> --relogin-delay 10" to git send-email ;)
Mel and Ondrej thanks a lot for the proposed solutions. I'm sure some of
your solutions will be used soon.
> --
> Ondrej Mosnacek
> Software Engineer, Platform Security - SELinux kernel
> Red Hat, Inc.
Regards,
John Wood
^ permalink raw reply
* Re: [PATCH v6 7/8] X.509: support OSCCA sm2-with-sm3 certificate verification
From: Gilad Ben-Yossef @ 2020-09-13 7:12 UTC (permalink / raw)
To: Tianjia Zhang
Cc: Herbert Xu, David S. Miller, David Howells, Maxime Coquelin,
Alexandre Torgue, James Morris, Serge E. Hallyn, Stephan Mueller,
Marcelo Henrique Cerri, Steven Rostedt (VMware), Masahiro Yamada,
Brendan Higgins, Andrew Morton, Johannes Weiner, Waiman Long,
Mimi Zohar, Lakshmi Ramasubramanian, Colin Ian King,
Tushar Sugandhi, Vitaly Chikunov, Pascal van Leeuwen,
Linux Crypto Mailing List, Linux kernel mailing list, keyrings,
linux-stm32, Linux ARM, linux-security-module, Xufeng Zhang,
Jia Zhang
In-Reply-To: <20200903131242.128665-8-tianjia.zhang@linux.alibaba.com>
Hi,
On Thu, Sep 3, 2020 at 4:13 PM Tianjia Zhang
<tianjia.zhang@linux.alibaba.com> wrote:
>
> The digital certificate format based on SM2 crypto algorithm as
> specified in GM/T 0015-2012. It was published by State Encryption
> Management Bureau, China.
>
> The method of generating Other User Information is defined as
> ZA=H256(ENTLA || IDA || a || b || xG || yG || xA || yA), it also
> specified in https://tools.ietf.org/html/draft-shen-sm2-ecdsa-02.
>
> The x509 certificate supports sm2-with-sm3 type certificate
> verification. Because certificate verification requires ZA
> in addition to tbs data, ZA also depends on elliptic curve
> parameters and public key data, so you need to access tbs in sig
> and calculate ZA. Finally calculate the digest of the
> signature and complete the verification work. The calculation
> process of ZA is declared in specifications GM/T 0009-2012
> and GM/T 0003.2-2012.
>
> Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
> Tested-by: Xufeng Zhang <yunbo.xufeng@linux.alibaba.com>
> ---
> crypto/asymmetric_keys/Makefile | 1 +
> crypto/asymmetric_keys/public_key.c | 6 +++
> crypto/asymmetric_keys/public_key_sm2.c | 61 ++++++++++++++++++++++++
> crypto/asymmetric_keys/x509_public_key.c | 3 ++
> include/crypto/public_key.h | 15 ++++++
> 5 files changed, 86 insertions(+)
> create mode 100644 crypto/asymmetric_keys/public_key_sm2.c
>
> diff --git a/crypto/asymmetric_keys/Makefile b/crypto/asymmetric_keys/Makefile
> index 28b91adba2ae..1a99ea5acb6b 100644
> --- a/crypto/asymmetric_keys/Makefile
> +++ b/crypto/asymmetric_keys/Makefile
> @@ -11,6 +11,7 @@ asymmetric_keys-y := \
> signature.o
>
> obj-$(CONFIG_ASYMMETRIC_PUBLIC_KEY_SUBTYPE) += public_key.o
> +obj-$(CONFIG_ASYMMETRIC_PUBLIC_KEY_SUBTYPE) += public_key_sm2.o
> obj-$(CONFIG_ASYMMETRIC_TPM_KEY_SUBTYPE) += asym_tpm.o
>
> #
> diff --git a/crypto/asymmetric_keys/public_key.c b/crypto/asymmetric_keys/public_key.c
> index d8410ffd7f12..1d0492098bbd 100644
> --- a/crypto/asymmetric_keys/public_key.c
> +++ b/crypto/asymmetric_keys/public_key.c
> @@ -299,6 +299,12 @@ int public_key_verify_signature(const struct public_key *pkey,
> if (ret)
> goto error_free_key;
>
> + if (strcmp(sig->pkey_algo, "sm2") == 0 && sig->data_size) {
> + ret = cert_sig_digest_update(sig, tfm);
> + if (ret)
> + goto error_free_key;
> + }
> +
> sg_init_table(src_sg, 2);
> sg_set_buf(&src_sg[0], sig->s, sig->s_size);
> sg_set_buf(&src_sg[1], sig->digest, sig->digest_size);
> diff --git a/crypto/asymmetric_keys/public_key_sm2.c b/crypto/asymmetric_keys/public_key_sm2.c
> new file mode 100644
> index 000000000000..7325cf21dbb4
> --- /dev/null
> +++ b/crypto/asymmetric_keys/public_key_sm2.c
> @@ -0,0 +1,61 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> +/*
> + * asymmetric public-key algorithm for SM2-with-SM3 certificate
> + * as specified by OSCCA GM/T 0003.1-2012 -- 0003.5-2012 SM2 and
> + * described at https://tools.ietf.org/html/draft-shen-sm2-ecdsa-02
> + *
> + * Copyright (c) 2020, Alibaba Group.
> + * Authors: Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
> + */
> +
> +#include <crypto/sm3_base.h>
> +#include <crypto/sm2.h>
> +#include <crypto/public_key.h>
> +
> +#if IS_REACHABLE(CONFIG_CRYPTO_SM2)
> +
> +int cert_sig_digest_update(const struct public_key_signature *sig,
> + struct crypto_akcipher *tfm_pkey)
> +{
> + struct crypto_shash *tfm;
> + struct shash_desc *desc;
> + size_t desc_size;
> + unsigned char dgst[SM3_DIGEST_SIZE];
> + int ret;
> +
> + BUG_ON(!sig->data);
> +
> + ret = sm2_compute_z_digest(tfm_pkey, SM2_DEFAULT_USERID,
> + SM2_DEFAULT_USERID_LEN, dgst);
> + if (ret)
> + return ret;
> +
> + tfm = crypto_alloc_shash(sig->hash_algo, 0, 0);
> + if (IS_ERR(tfm))
> + return PTR_ERR(tfm);
> +
> + desc_size = crypto_shash_descsize(tfm) + sizeof(*desc);
> + desc = kzalloc(desc_size, GFP_KERNEL);
> + if (!desc)
> + goto error_free_tfm;
> +
> + desc->tfm = tfm;
> +
> + ret = crypto_shash_init(desc);
> + if (ret < 0)
> + goto error_free_desc;
> +
> + ret = crypto_shash_update(desc, dgst, SM3_DIGEST_SIZE);
> + if (ret < 0)
> + goto error_free_desc;
> +
> + ret = crypto_shash_finup(desc, sig->data, sig->data_size, sig->digest);
It looks like you are doing a separate init, update, finup every time
- I would consider using crypto_shash_digest() in one go.
In fact, considering the fact that you are allocating a tfm just for
this use and then releasing it, I would consider switching to
crypto_shash_tfm_digest() and dropping the kzalloc all together.
This should simplify the code a bit.
Other than that I don't have anything smart to say :-)
Gilad
--
Gilad Ben-Yossef
Chief Coffee Drinker
values of β will give rise to dom!
^ permalink raw reply
* Re: [RESEND][RFC PATCH 0/6] Fork brute force attack mitigation (fbfam)
From: Ondrej Mosnacek @ 2020-09-12 20:48 UTC (permalink / raw)
To: Mel Gorman
Cc: John Wood, James Morris, Kees Cook, Kernel Hardening,
Matthew Wilcox, Jonathan Corbet, Alexander Viro, Ingo Molnar,
Peter Zijlstra, Juri Lelli, Vincent Guittot, Dietmar Eggemann,
Steven Rostedt, Ben Segall, Luis Chamberlain, Iurii Zaikin,
Serge E. Hallyn, linux-doc, Linux kernel mailing list,
linux-fsdevel, Linux Security Module list
In-Reply-To: <20200912144722.GE3117@suse.de>
On Sat, Sep 12, 2020 at 4:51 PM Mel Gorman <mgorman@suse.de> wrote:
> On Sat, Sep 12, 2020 at 11:36:52AM +0200, John Wood wrote:
> > On Sat, Sep 12, 2020 at 12:56:18AM -0700, Kees Cook wrote:
> > > On Sat, Sep 12, 2020 at 10:03:23AM +1000, James Morris wrote:
> > > > On Thu, 10 Sep 2020, Kees Cook wrote:
> > > >
> > > > > [kees: re-sending this series on behalf of John Wood <john.wood@gmx.com>
> > > > > also visible at https://github.com/johwood/linux fbfam]
> > > > >
> > > > > From: John Wood <john.wood@gmx.com>
> > > >
> > > > Why are you resending this? The author of the code needs to be able to
> > > > send and receive emails directly as part of development and maintenance.
> >
> > I tried to send the full patch serie by myself but my email got blocked. After
> > get support from my email provider it told to me that my account is young,
> > and due to its spam policie I am not allow, for now, to send a big amount
> > of mails in a short period. They also informed me that soon I will be able
> > to send more mails. The quantity increase with the age of the account.
> >
>
> If you're using "git send-email" then specify --confirm=always and
> either manually send a mail every few seconds or use an expect script
> like
>
> #!/bin/bash
> EXPECT_SCRIPT=
> function cleanup() {
> if [ "$EXPECT_SCRIPT" != "" ]; then
> rm $EXPECT_SCRIPT
> fi
> }
> trap cleanup EXIT
>
> EXPECT_SCRIPT=`mktemp`
> cat > $EXPECT_SCRIPT <<EOF
> spawn sh ./SEND
> expect {
> "Send this email" { sleep 10; exp_send y\\r; exp_continue }
> }
> EOF
>
> expect -f $EXPECT_SCRIPT
> exit $?
>
> This will work if your provider limits the rate mails are sent rather
> than the total amount.
...or you could keep it simple and just pass "--batch-size 1
--relogin-delay 10" to git send-email ;)
--
Ondrej Mosnacek
Software Engineer, Platform Security - SELinux kernel
Red Hat, Inc.
^ permalink raw reply
* Re: [RESEND][RFC PATCH 0/6] Fork brute force attack mitigation (fbfam)
From: Mel Gorman @ 2020-09-12 14:47 UTC (permalink / raw)
To: John Wood
Cc: James Morris, Kees Cook, kernel-hardening, Matthew Wilcox,
Jonathan Corbet, Alexander Viro, Ingo Molnar, Peter Zijlstra,
Juri Lelli, Vincent Guittot, Dietmar Eggemann, Steven Rostedt,
Ben Segall, Luis Chamberlain, Iurii Zaikin, Serge E. Hallyn,
linux-doc, linux-kernel, linux-fsdevel, linux-security-module
In-Reply-To: <20200912093652.GA3041@ubuntu>
On Sat, Sep 12, 2020 at 11:36:52AM +0200, John Wood wrote:
> On Sat, Sep 12, 2020 at 12:56:18AM -0700, Kees Cook wrote:
> > On Sat, Sep 12, 2020 at 10:03:23AM +1000, James Morris wrote:
> > > On Thu, 10 Sep 2020, Kees Cook wrote:
> > >
> > > > [kees: re-sending this series on behalf of John Wood <john.wood@gmx.com>
> > > > also visible at https://github.com/johwood/linux fbfam]
> > > >
> > > > From: John Wood <john.wood@gmx.com>
> > >
> > > Why are you resending this? The author of the code needs to be able to
> > > send and receive emails directly as part of development and maintenance.
>
> I tried to send the full patch serie by myself but my email got blocked. After
> get support from my email provider it told to me that my account is young,
> and due to its spam policie I am not allow, for now, to send a big amount
> of mails in a short period. They also informed me that soon I will be able
> to send more mails. The quantity increase with the age of the account.
>
If you're using "git send-email" then specify --confirm=always and
either manually send a mail every few seconds or use an expect script
like
#!/bin/bash
EXPECT_SCRIPT=
function cleanup() {
if [ "$EXPECT_SCRIPT" != "" ]; then
rm $EXPECT_SCRIPT
fi
}
trap cleanup EXIT
EXPECT_SCRIPT=`mktemp`
cat > $EXPECT_SCRIPT <<EOF
spawn sh ./SEND
expect {
"Send this email" { sleep 10; exp_send y\\r; exp_continue }
}
EOF
expect -f $EXPECT_SCRIPT
exit $?
This will work if your provider limits the rate mails are sent rather
than the total amount.
--
Mel Gorman
SUSE Labs
^ permalink raw reply
* Re: [RESEND][RFC PATCH 0/6] Fork brute force attack mitigation (fbfam)
From: John Wood @ 2020-09-12 12:24 UTC (permalink / raw)
To: Kees Cook
Cc: kernel-hardening, John Wood, Jann Horn, Matthew Wilcox,
Jonathan Corbet, Alexander Viro, Ingo Molnar, Peter Zijlstra,
Juri Lelli, Vincent Guittot, Dietmar Eggemann, Steven Rostedt,
Ben Segall, Mel Gorman, Luis Chamberlain, Iurii Zaikin,
James Morris, Serge E. Hallyn, linux-doc, linux-kernel,
linux-fsdevel, linux-security-module
In-Reply-To: <202009120053.9FB7F2A7@keescook>
On Sat, Sep 12, 2020 at 12:55:03AM -0700, Kees Cook wrote:
> On Fri, Sep 11, 2020 at 04:48:06PM +0200, John Wood wrote:
> > My original patch serie is composed of 9 patches, so the 3 lasts are lost.
> > Kees: Have you removed them for some reason? Can you send them for review?
> >
> > security/fbfam: Add two new prctls to enable and disable the fbfam feature
> > https://github.com/johwood/linux/commit/8a36399847213e7eb7b45b853568a53666bd0083
> >
> > Documentation/security: Add documentation for the fbfam feature
> > https://github.com/johwood/linux/commit/fb46804541f5c0915f3f48acefbe6dc998815609
> >
> > MAINTAINERS: Add a new entry for the fbfam feature
> > https://github.com/johwood/linux/commit/4303bc8935334136c6ef47b5e50b87cd2c472c1f
>
> Oh, hm, I'm not sure where they went. I think they were missing from my
> inbox when I saved your series from email. An oversight on my part;
> apologies!
I sent the full serie to Matthew Wilcox <willy@infradead.org> only, as he
wanted to help re-sending the full serie. Then I saw that only 6 patches
appeared in the linux-doc mailing list.
I can try to send the three pending patches in different stages (for example
one patch every 4 or 5 hours) to avoid blocking my email. I hope. Or I can
send the three pending patches only to the kernel-hardening mailing list
and you re-send to all the people involved. Or any other solution you
propose. It's up to you.
> > Is there a problem if I ask for some guidance (replying to this thread)
> > during the process to do my second patch series?
>
> Please feel free! I'm happy to help. :)
It's a pleasure working with you. Thanks a lot.
> --
> Kees Cook
Regards,
John Wood
^ permalink raw reply
* Re: [RESEND][RFC PATCH 0/6] Fork brute force attack mitigation (fbfam)
From: John Wood @ 2020-09-12 9:36 UTC (permalink / raw)
To: James Morris
Cc: Kees Cook, kernel-hardening, John Wood, Matthew Wilcox,
Jonathan Corbet, Alexander Viro, Ingo Molnar, Peter Zijlstra,
Juri Lelli, Vincent Guittot, Dietmar Eggemann, Steven Rostedt,
Ben Segall, Mel Gorman, Luis Chamberlain, Iurii Zaikin,
Serge E. Hallyn, linux-doc, linux-kernel, linux-fsdevel,
linux-security-module
In-Reply-To: <202009120055.F6BF704620@keescook>
On Sat, Sep 12, 2020 at 12:56:18AM -0700, Kees Cook wrote:
> On Sat, Sep 12, 2020 at 10:03:23AM +1000, James Morris wrote:
> > On Thu, 10 Sep 2020, Kees Cook wrote:
> >
> > > [kees: re-sending this series on behalf of John Wood <john.wood@gmx.com>
> > > also visible at https://github.com/johwood/linux fbfam]
> > >
> > > From: John Wood <john.wood@gmx.com>
> >
> > Why are you resending this? The author of the code needs to be able to
> > send and receive emails directly as part of development and maintenance.
I tried to send the full patch serie by myself but my email got blocked. After
get support from my email provider it told to me that my account is young,
and due to its spam policie I am not allow, for now, to send a big amount
of mails in a short period. They also informed me that soon I will be able
to send more mails. The quantity increase with the age of the account.
I hope that for the next version all works as expected.
Apologies.
> I wanted to flush it from my "review" TODO list, mainly.
Thanks Kees for the re-send and review.
> --
> Kees Cook
Regards,
John Wood
^ permalink raw reply
* Re: [PATCH v6 6/8] X.509: support OSCCA certificate parse
From: Vitaly Chikunov @ 2020-09-12 8:50 UTC (permalink / raw)
To: Tianjia Zhang
Cc: Herbert Xu, David S. Miller, David Howells, Maxime Coquelin,
Alexandre Torgue, James Morris, Serge E. Hallyn, Stephan Mueller,
Marcelo Henrique Cerri, Steven Rostedt (VMware), Masahiro Yamada,
Brendan Higgins, Andrew Morton, Johannes Weiner, Waiman Long,
Mimi Zohar, Lakshmi Ramasubramanian, Colin Ian King,
Tushar Sugandhi, Gilad Ben-Yossef, Pascal van Leeuwen,
linux-crypto, linux-kernel, keyrings, linux-stm32,
linux-arm-kernel, linux-security-module, Xufeng Zhang, Jia Zhang
In-Reply-To: <20200903131242.128665-7-tianjia.zhang@linux.alibaba.com>
On Thu, Sep 03, 2020 at 09:12:40PM +0800, Tianjia Zhang wrote:
> The digital certificate format based on SM2 crypto algorithm as
> specified in GM/T 0015-2012. It was published by State Encryption
> Management Bureau, China.
>
> This patch adds the OID object identifier defined by OSCCA. The
> x509 certificate supports sm2-with-sm3 type certificate parsing.
> It uses the standard elliptic curve public key, and the sm2
> algorithm signs the hash generated by sm3.
>
> Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
> Tested-by: Xufeng Zhang <yunbo.xufeng@linux.alibaba.com>
> ---
> crypto/asymmetric_keys/x509_cert_parser.c | 14 +++++++++++++-
> include/linux/oid_registry.h | 6 ++++++
> 2 files changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/crypto/asymmetric_keys/x509_cert_parser.c b/crypto/asymmetric_keys/x509_cert_parser.c
> index 26ec20ef4899..6a8aee22bfd4 100644
> --- a/crypto/asymmetric_keys/x509_cert_parser.c
> +++ b/crypto/asymmetric_keys/x509_cert_parser.c
> @@ -234,6 +234,10 @@ int x509_note_pkey_algo(void *context, size_t hdrlen,
> case OID_gost2012Signature512:
> ctx->cert->sig->hash_algo = "streebog512";
> goto ecrdsa;
> +
> + case OID_sm2_with_sm3:
> + ctx->cert->sig->hash_algo = "sm3";
> + goto sm2;
> }
>
> rsa_pkcs1:
> @@ -246,6 +250,11 @@ int x509_note_pkey_algo(void *context, size_t hdrlen,
> ctx->cert->sig->encoding = "raw";
> ctx->algo_oid = ctx->last_oid;
> return 0;
> +sm2:
> + ctx->cert->sig->pkey_algo = "sm2";
> + ctx->cert->sig->encoding = "raw";
> + ctx->algo_oid = ctx->last_oid;
> + return 0;
> }
>
> /*
> @@ -266,7 +275,8 @@ int x509_note_signature(void *context, size_t hdrlen,
> }
>
> if (strcmp(ctx->cert->sig->pkey_algo, "rsa") == 0 ||
> - strcmp(ctx->cert->sig->pkey_algo, "ecrdsa") == 0) {
> + strcmp(ctx->cert->sig->pkey_algo, "ecrdsa") == 0 ||
> + strcmp(ctx->cert->sig->pkey_algo, "sm2") == 0) {
> /* Discard the BIT STRING metadata */
> if (vlen < 1 || *(const u8 *)value != 0)
> return -EBADMSG;
> @@ -456,6 +466,8 @@ int x509_extract_key_data(void *context, size_t hdrlen,
> else if (ctx->last_oid == OID_gost2012PKey256 ||
> ctx->last_oid == OID_gost2012PKey512)
> ctx->cert->pub->pkey_algo = "ecrdsa";
> + else if (ctx->last_oid == OID_id_ecPublicKey)
> + ctx->cert->pub->pkey_algo = "sm2";
> else
> return -ENOPKG;
>
> diff --git a/include/linux/oid_registry.h b/include/linux/oid_registry.h
> index 657d6bf2c064..48fe3133ff39 100644
> --- a/include/linux/oid_registry.h
> +++ b/include/linux/oid_registry.h
> @@ -107,6 +107,12 @@ enum OID {
> OID_gostTC26Sign512B, /* 1.2.643.7.1.2.1.2.2 */
> OID_gostTC26Sign512C, /* 1.2.643.7.1.2.1.2.3 */
>
> + /* OSCCA */
> + OID_sm2, /* 1.2.156.10197.1.301 */
> + OID_sm3, /* 1.2.156.10197.1.401 */
> + OID_sm2_with_sm3, /* 1.2.156.10197.1.501 */
> + OID_sm3WithRSAEncryption, /* 1.2.156.10197.1.504 */
OID_sm3WithRSAEncryption identifier is unused and this mode looks not
implemented. But, this is probably ok for possible future extension.
Reviewed-by: Vitaly Chikunov <vt@altlinux.org>
Thanks,
> +
> OID__NR
> };
>
^ 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