While reviewing Scott Branden's submission of the new Broadcom VK driver
driver upstream [0], part of which included 4 new pread varaints of the
existing kernel_read*(), calls I grew shivers of the possibility of drivers
using these exported symbols loosely. If we're going to grow these, it
seems best to restrict the symbols to a namespace so drivers and
subsystem maintainers don't use these carelessly.
This should also help with making it easier to audit future locations in
the kernel such read calls happen by just looking at the imports of the
namespace.
This goes compile tested with allyesconfig and allmodconfig on x86_64.
0-day should have a report on build status with other configs later of
my branch [1].
[0] https://lkml.kernel.org/r/[email protected]
[1] https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux-next.git/log/?h=20200513-kernel-read-sym
Luis Chamberlain (3):
fs: unexport kernel_read_file()
security: add symbol namespace for reading file data
fs: move kernel_read*() calls to its own symbol namespace
drivers/base/firmware_loader/fallback.c | 1 +
drivers/base/firmware_loader/main.c | 1 +
fs/exec.c | 9 +++++----
kernel/kexec.c | 2 ++
kernel/kexec_file.c | 2 ++
kernel/module.c | 3 +++
security/integrity/digsig.c | 3 +++
security/integrity/ima/ima_fs.c | 3 +++
security/integrity/ima/ima_main.c | 2 ++
security/loadpin/loadpin.c | 2 ++
security/security.c | 8 +++++---
security/selinux/hooks.c | 2 ++
12 files changed, 31 insertions(+), 7 deletions(-)
--
2.26.2
Signed-off-by: Luis Chamberlain <[email protected]>
---
drivers/base/firmware_loader/main.c | 1 +
fs/exec.c | 6 +++---
kernel/kexec_file.c | 2 ++
kernel/module.c | 1 +
security/integrity/digsig.c | 3 +++
security/integrity/ima/ima_fs.c | 3 +++
security/integrity/ima/ima_main.c | 2 ++
security/loadpin/loadpin.c | 2 ++
security/security.c | 2 ++
security/selinux/hooks.c | 2 ++
10 files changed, 21 insertions(+), 3 deletions(-)
diff --git a/drivers/base/firmware_loader/main.c b/drivers/base/firmware_loader/main.c
index 5296aaca35cf..a5ed796a9166 100644
--- a/drivers/base/firmware_loader/main.c
+++ b/drivers/base/firmware_loader/main.c
@@ -44,6 +44,7 @@
MODULE_AUTHOR("Manuel Estrada Sainz");
MODULE_DESCRIPTION("Multi purpose firmware loading support");
MODULE_LICENSE("GPL");
+MODULE_IMPORT_NS(CORE_FS_READ);
struct firmware_cache {
/* firmware_buf instance will be added into the below list */
diff --git a/fs/exec.c b/fs/exec.c
index 30bd800ab1d6..bbe2a35ea2e0 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -1008,7 +1008,7 @@ int kernel_read_file_from_path(const char *path, void **buf, loff_t *size,
fput(file);
return ret;
}
-EXPORT_SYMBOL_GPL(kernel_read_file_from_path);
+EXPORT_SYMBOL_NS_GPL(kernel_read_file_from_path, CORE_FS_READ);
int kernel_read_file_from_path_initns(const char *path, void **buf,
loff_t *size, loff_t max_size,
@@ -1034,7 +1034,7 @@ int kernel_read_file_from_path_initns(const char *path, void **buf,
fput(file);
return ret;
}
-EXPORT_SYMBOL_GPL(kernel_read_file_from_path_initns);
+EXPORT_SYMBOL_NS_GPL(kernel_read_file_from_path_initns, CORE_FS_READ);
int kernel_read_file_from_fd(int fd, void **buf, loff_t *size, loff_t max_size,
enum kernel_read_file_id id)
@@ -1050,7 +1050,7 @@ int kernel_read_file_from_fd(int fd, void **buf, loff_t *size, loff_t max_size,
fdput(f);
return ret;
}
-EXPORT_SYMBOL_GPL(kernel_read_file_from_fd);
+EXPORT_SYMBOL_NS_GPL(kernel_read_file_from_fd, CORE_FS_READ);
ssize_t read_code(struct file *file, unsigned long addr, loff_t pos, size_t len)
{
diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
index bb05fd52de85..d96b7c05b0a5 100644
--- a/kernel/kexec_file.c
+++ b/kernel/kexec_file.c
@@ -28,6 +28,8 @@
#include <linux/vmalloc.h>
#include "kexec_internal.h"
+MODULE_IMPORT_NS(CORE_FS_READ);
+
static int kexec_calculate_store_digests(struct kimage *image);
/*
diff --git a/kernel/module.c b/kernel/module.c
index 8973a463712e..f14868980080 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -60,6 +60,7 @@
#include "module-internal.h"
MODULE_IMPORT_NS(SECURITY_READ);
+MODULE_IMPORT_NS(CORE_FS_READ);
#define CREATE_TRACE_POINTS
#include <trace/events/module.h>
diff --git a/security/integrity/digsig.c b/security/integrity/digsig.c
index e9cbadade74b..d68ef41a3987 100644
--- a/security/integrity/digsig.c
+++ b/security/integrity/digsig.c
@@ -13,11 +13,14 @@
#include <linux/key-type.h>
#include <linux/digsig.h>
#include <linux/vmalloc.h>
+#include <linux/module.h>
#include <crypto/public_key.h>
#include <keys/system_keyring.h>
#include "integrity.h"
+MODULE_IMPORT_NS(CORE_FS_READ);
+
static struct key *keyring[INTEGRITY_KEYRING_MAX];
static const char * const keyring_name[INTEGRITY_KEYRING_MAX] = {
diff --git a/security/integrity/ima/ima_fs.c b/security/integrity/ima/ima_fs.c
index e3fcad871861..41fd03281ae1 100644
--- a/security/integrity/ima/ima_fs.c
+++ b/security/integrity/ima/ima_fs.c
@@ -20,6 +20,9 @@
#include <linux/rcupdate.h>
#include <linux/parser.h>
#include <linux/vmalloc.h>
+#include <linux/module.h>
+
+MODULE_IMPORT_NS(CORE_FS_READ);
#include "ima.h"
diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c
index f96f151294e6..ffa7a14deef1 100644
--- a/security/integrity/ima/ima_main.c
+++ b/security/integrity/ima/ima_main.c
@@ -28,6 +28,8 @@
#include "ima.h"
+MODULE_IMPORT_NS(CORE_FS_READ);
+
#ifdef CONFIG_IMA_APPRAISE
int ima_appraise = IMA_APPRAISE_ENFORCE;
#else
diff --git a/security/loadpin/loadpin.c b/security/loadpin/loadpin.c
index ee5cb944f4ad..ca2022ad5f88 100644
--- a/security/loadpin/loadpin.c
+++ b/security/loadpin/loadpin.c
@@ -17,6 +17,8 @@
#include <linux/sched.h> /* current */
#include <linux/string_helpers.h>
+MODULE_IMPORT_NS(CORE_FS_READ);
+
static void report_load(const char *origin, struct file *file, char *operation)
{
char *cmdline, *pathname;
diff --git a/security/security.c b/security/security.c
index bdbd1fc5105a..c865f1de4b03 100644
--- a/security/security.c
+++ b/security/security.c
@@ -29,6 +29,8 @@
#include <linux/msg.h>
#include <net/flow.h>
+MODULE_IMPORT_NS(CORE_FS_READ);
+
#define MAX_LSM_EVM_XATTR 2
/* How many LSMs were built into the kernel? */
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 9979b45e0a34..6dc4abfbfb78 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -103,6 +103,8 @@
#include "audit.h"
#include "avc_ss.h"
+MODULE_IMPORT_NS(CORE_FS_READ);
+
struct selinux_state selinux_state;
/* SECMARK reference count */
--
2.26.2
Certain symbols are not meant to be used by everybody, the security
helpers for reading files directly is one such case. Use a symbol
namespace for them.
This will prevent abuse of use of these symbols in places they were
not inteded to be used, and provides an easy way to audit where these
types of operations happen as a whole.
Signed-off-by: Luis Chamberlain <[email protected]>
---
drivers/base/firmware_loader/fallback.c | 1 +
fs/exec.c | 2 ++
kernel/kexec.c | 2 ++
kernel/module.c | 2 ++
security/security.c | 6 +++---
5 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/base/firmware_loader/fallback.c b/drivers/base/firmware_loader/fallback.c
index d9ac7296205e..b088886dafda 100644
--- a/drivers/base/firmware_loader/fallback.c
+++ b/drivers/base/firmware_loader/fallback.c
@@ -19,6 +19,7 @@
*/
MODULE_IMPORT_NS(FIRMWARE_LOADER_PRIVATE);
+MODULE_IMPORT_NS(SECURITY_READ);
extern struct firmware_fallback_config fw_fallback_config;
diff --git a/fs/exec.c b/fs/exec.c
index 9791b9eef9ce..30bd800ab1d6 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -72,6 +72,8 @@
#include <trace/events/sched.h>
+MODULE_IMPORT_NS(SECURITY_READ);
+
int suid_dumpable = 0;
static LIST_HEAD(formats);
diff --git a/kernel/kexec.c b/kernel/kexec.c
index f977786fe498..8d572b41a157 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -19,6 +19,8 @@
#include "kexec_internal.h"
+MODULE_IMPORT_NS(SECURITY_READ);
+
static int copy_user_segment_list(struct kimage *image,
unsigned long nr_segments,
struct kexec_segment __user *segments)
diff --git a/kernel/module.c b/kernel/module.c
index 80faaf2116dd..8973a463712e 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -59,6 +59,8 @@
#include <uapi/linux/module.h>
#include "module-internal.h"
+MODULE_IMPORT_NS(SECURITY_READ);
+
#define CREATE_TRACE_POINTS
#include <trace/events/module.h>
diff --git a/security/security.c b/security/security.c
index 8ae66e4c370f..bdbd1fc5105a 100644
--- a/security/security.c
+++ b/security/security.c
@@ -1654,7 +1654,7 @@ int security_kernel_read_file(struct file *file, enum kernel_read_file_id id)
return ret;
return ima_read_file(file, id);
}
-EXPORT_SYMBOL_GPL(security_kernel_read_file);
+EXPORT_SYMBOL_NS_GPL(security_kernel_read_file, SECURITY_READ);
int security_kernel_post_read_file(struct file *file, char *buf, loff_t size,
enum kernel_read_file_id id)
@@ -1666,7 +1666,7 @@ int security_kernel_post_read_file(struct file *file, char *buf, loff_t size,
return ret;
return ima_post_read_file(file, buf, size, id);
}
-EXPORT_SYMBOL_GPL(security_kernel_post_read_file);
+EXPORT_SYMBOL_NS_GPL(security_kernel_post_read_file, SECURITY_READ);
int security_kernel_load_data(enum kernel_load_data_id id)
{
@@ -1677,7 +1677,7 @@ int security_kernel_load_data(enum kernel_load_data_id id)
return ret;
return ima_load_data(id);
}
-EXPORT_SYMBOL_GPL(security_kernel_load_data);
+EXPORT_SYMBOL_NS_GPL(security_kernel_load_data, SECURITY_READ);
int security_task_fix_setuid(struct cred *new, const struct cred *old,
int flags)
--
2.26.2
There are no modular uses of kernel_read_file(), so just unexport it.
Suggested-by: Al Viro <[email protected]>
Signed-off-by: Luis Chamberlain <[email protected]>
---
fs/exec.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/fs/exec.c b/fs/exec.c
index 23dc2b45d590..9791b9eef9ce 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -988,7 +988,6 @@ int kernel_read_file(struct file *file, void **buf, loff_t *size,
allow_write_access(file);
return ret;
}
-EXPORT_SYMBOL_GPL(kernel_read_file);
int kernel_read_file_from_path(const char *path, void **buf, loff_t *size,
loff_t max_size, enum kernel_read_file_id id)
--
2.26.2
On Wed, May 13, 2020 at 10:40:31AM -0500, Eric W. Biederman wrote:
> Luis Chamberlain <[email protected]> writes:
>
> > Certain symbols are not meant to be used by everybody, the security
> > helpers for reading files directly is one such case. Use a symbol
> > namespace for them.
> >
> > This will prevent abuse of use of these symbols in places they were
> > not inteded to be used, and provides an easy way to audit where these
> > types of operations happen as a whole.
>
> Why not just remove the ability for the firmware loader to be a module?
I agree, it's been a mess of build options to try to keep alive over
time.
> Is there some important use case that requires the firmware loader
> to be a module?
I don't think so anymore.
> We already compile the code in by default. So it is probably just
> easier to remove the modular support all together. Which would allow
> the export of the security hooks to be removed as well.
Agreed.
thanks,
greg k-h
On Wed, May 13, 2020 at 10:40:31AM -0500, Eric W. Biederman wrote:
> Luis Chamberlain <[email protected]> writes:
>
> > Certain symbols are not meant to be used by everybody, the security
> > helpers for reading files directly is one such case. Use a symbol
> > namespace for them.
> >
> > This will prevent abuse of use of these symbols in places they were
> > not inteded to be used, and provides an easy way to audit where these
> > types of operations happen as a whole.
>
> Why not just remove the ability for the firmware loader to be a module?
>
> Is there some important use case that requires the firmware loader
> to be a module?
>
> We already compile the code in by default. So it is probably just
> easier to remove the modular support all together. Which would allow
> the export of the security hooks to be removed as well.
Yeah, that's a better solution. The only constaint I am aware of is
we *cannot* change the name of the module from firmware_class since the
old fallback sysfs loader depends on the module name. So, so long as we
take care with that on built-in and document this very well, I think
we should be good.
I checked the commit logs and this was tristate since the code was added
upstream, so I cannot see any good reason it was enabled as modular.
Speaking with a *backports experience* hat on, we did have a use case
to use a module for it in case a new feature was added upstream which
was not present on older kernels. However I think that using a separate
symbol prefix would help with that.
Would any Android stakeholders / small / embedded folks whave any issue
with this?
Luis
On Wed, May 13, 2020 at 04:16:22PM +0000, Luis Chamberlain wrote:
> On Wed, May 13, 2020 at 10:40:31AM -0500, Eric W. Biederman wrote:
> > Luis Chamberlain <[email protected]> writes:
> >
> > > Certain symbols are not meant to be used by everybody, the security
> > > helpers for reading files directly is one such case. Use a symbol
> > > namespace for them.
> > >
> > > This will prevent abuse of use of these symbols in places they were
> > > not inteded to be used, and provides an easy way to audit where these
> > > types of operations happen as a whole.
> >
> > Why not just remove the ability for the firmware loader to be a module?
> >
> > Is there some important use case that requires the firmware loader
> > to be a module?
> >
> > We already compile the code in by default. So it is probably just
> > easier to remove the modular support all together. Which would allow
> > the export of the security hooks to be removed as well.
>
> Yeah, that's a better solution. The only constaint I am aware of is
> we *cannot* change the name of the module from firmware_class since the
> old fallback sysfs loader depends on the module name. So, so long as we
> take care with that on built-in and document this very well, I think
> we should be good.
>
> I checked the commit logs and this was tristate since the code was added
> upstream, so I cannot see any good reason it was enabled as modular.
>
> Speaking with a *backports experience* hat on, we did have a use case
> to use a module for it in case a new feature was added upstream which
> was not present on older kernels. However I think that using a separate
> symbol prefix would help with that.
>
> Would any Android stakeholders / small / embedded folks whave any issue
> with this?
As long as you can still *completely* compile out firmware loading, I
don't think there's a huge use case for making it modular. y/n seems
fine.
Can you also move kernel_read_* out of fs.h? That header gets pulled
in just about everywhere and doesn't really need function not related
to the general fs interface.
Luis Chamberlain <[email protected]> writes:
> Certain symbols are not meant to be used by everybody, the security
> helpers for reading files directly is one such case. Use a symbol
> namespace for them.
>
> This will prevent abuse of use of these symbols in places they were
> not inteded to be used, and provides an easy way to audit where these
> types of operations happen as a whole.
Why not just remove the ability for the firmware loader to be a module?
Is there some important use case that requires the firmware loader
to be a module?
We already compile the code in by default. So it is probably just
easier to remove the modular support all together. Which would allow
the export of the security hooks to be removed as well.
Eric
> Signed-off-by: Luis Chamberlain <[email protected]>
> ---
> drivers/base/firmware_loader/fallback.c | 1 +
> fs/exec.c | 2 ++
> kernel/kexec.c | 2 ++
> kernel/module.c | 2 ++
> security/security.c | 6 +++---
> 5 files changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/base/firmware_loader/fallback.c b/drivers/base/firmware_loader/fallback.c
> index d9ac7296205e..b088886dafda 100644
> --- a/drivers/base/firmware_loader/fallback.c
> +++ b/drivers/base/firmware_loader/fallback.c
> @@ -19,6 +19,7 @@
> */
>
> MODULE_IMPORT_NS(FIRMWARE_LOADER_PRIVATE);
> +MODULE_IMPORT_NS(SECURITY_READ);
>
> extern struct firmware_fallback_config fw_fallback_config;
>
> diff --git a/fs/exec.c b/fs/exec.c
> index 9791b9eef9ce..30bd800ab1d6 100644
> --- a/fs/exec.c
> +++ b/fs/exec.c
> @@ -72,6 +72,8 @@
>
> #include <trace/events/sched.h>
>
> +MODULE_IMPORT_NS(SECURITY_READ);
> +
> int suid_dumpable = 0;
>
> static LIST_HEAD(formats);
> diff --git a/kernel/kexec.c b/kernel/kexec.c
> index f977786fe498..8d572b41a157 100644
> --- a/kernel/kexec.c
> +++ b/kernel/kexec.c
> @@ -19,6 +19,8 @@
>
> #include "kexec_internal.h"
>
> +MODULE_IMPORT_NS(SECURITY_READ);
> +
> static int copy_user_segment_list(struct kimage *image,
> unsigned long nr_segments,
> struct kexec_segment __user *segments)
> diff --git a/kernel/module.c b/kernel/module.c
> index 80faaf2116dd..8973a463712e 100644
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -59,6 +59,8 @@
> #include <uapi/linux/module.h>
> #include "module-internal.h"
>
> +MODULE_IMPORT_NS(SECURITY_READ);
> +
> #define CREATE_TRACE_POINTS
> #include <trace/events/module.h>
>
> diff --git a/security/security.c b/security/security.c
> index 8ae66e4c370f..bdbd1fc5105a 100644
> --- a/security/security.c
> +++ b/security/security.c
> @@ -1654,7 +1654,7 @@ int security_kernel_read_file(struct file *file, enum kernel_read_file_id id)
> return ret;
> return ima_read_file(file, id);
> }
> -EXPORT_SYMBOL_GPL(security_kernel_read_file);
> +EXPORT_SYMBOL_NS_GPL(security_kernel_read_file, SECURITY_READ);
>
> int security_kernel_post_read_file(struct file *file, char *buf, loff_t size,
> enum kernel_read_file_id id)
> @@ -1666,7 +1666,7 @@ int security_kernel_post_read_file(struct file *file, char *buf, loff_t size,
> return ret;
> return ima_post_read_file(file, buf, size, id);
> }
> -EXPORT_SYMBOL_GPL(security_kernel_post_read_file);
> +EXPORT_SYMBOL_NS_GPL(security_kernel_post_read_file, SECURITY_READ);
>
> int security_kernel_load_data(enum kernel_load_data_id id)
> {
> @@ -1677,7 +1677,7 @@ int security_kernel_load_data(enum kernel_load_data_id id)
> return ret;
> return ima_load_data(id);
> }
> -EXPORT_SYMBOL_GPL(security_kernel_load_data);
> +EXPORT_SYMBOL_NS_GPL(security_kernel_load_data, SECURITY_READ);
>
> int security_task_fix_setuid(struct cred *new, const struct cred *old,
> int flags)
On Wed, May 13, 2020 at 04:16:22PM +0000, Luis Chamberlain wrote:
> On Wed, May 13, 2020 at 10:40:31AM -0500, Eric W. Biederman wrote:
> > Luis Chamberlain <[email protected]> writes:
> >
> > > Certain symbols are not meant to be used by everybody, the security
> > > helpers for reading files directly is one such case. Use a symbol
> > > namespace for them.
> > >
> > > This will prevent abuse of use of these symbols in places they were
> > > not inteded to be used, and provides an easy way to audit where these
> > > types of operations happen as a whole.
> >
> > Why not just remove the ability for the firmware loader to be a module?
> >
> > Is there some important use case that requires the firmware loader
> > to be a module?
> >
> > We already compile the code in by default. So it is probably just
> > easier to remove the modular support all together. Which would allow
> > the export of the security hooks to be removed as well.
>
> Yeah, that's a better solution. The only constaint I am aware of is
> we *cannot* change the name of the module from firmware_class since the
> old fallback sysfs loader depends on the module name. So, so long as we
> take care with that on built-in and document this very well, I think
> we should be good.
>
> I checked the commit logs and this was tristate since the code was added
> upstream, so I cannot see any good reason it was enabled as modular.
>
> Speaking with a *backports experience* hat on, we did have a use case
> to use a module for it in case a new feature was added upstream which
> was not present on older kernels. However I think that using a separate
> symbol prefix would help with that.
>
> Would any Android stakeholders / small / embedded folks whave any issue
> with this?
Android has build in the firmware loading logic for a while now. Well,
always, they have not had kernel modules for many years. That is
changing but this logic is not getting moved to a kernel module as that
would just be silly :)
thanks,
greg k-h
On Wed, May 13, 2020 at 03:21:08PM +0000, Luis Chamberlain wrote:
> Signed-off-by: Luis Chamberlain <[email protected]>
I can't take patches without any changelog text at all, sorry.
greg k-h
On Wed, May 13, 2020 at 11:17:36AM -0700, Christoph Hellwig wrote:
> Can you also move kernel_read_* out of fs.h? That header gets pulled
> in just about everywhere and doesn't really need function not related
> to the general fs interface.
Sure, where should I dump these?
Luis
On Fri, May 15, 2020 at 09:29:33PM +0000, Luis Chamberlain wrote:
> On Wed, May 13, 2020 at 11:17:36AM -0700, Christoph Hellwig wrote:
> > Can you also move kernel_read_* out of fs.h? That header gets pulled
> > in just about everywhere and doesn't really need function not related
> > to the general fs interface.
>
> Sure, where should I dump these?
Maybe a new linux/kernel_read_file.h? Bonus points for a small top
of the file comment explaining the point of the interface, which I
still don't get :)
Hi Christoph,
On Sun, 2020-05-17 at 23:22 -0700, Christoph Hellwig wrote:
> On Fri, May 15, 2020 at 09:29:33PM +0000, Luis Chamberlain wrote:
> > On Wed, May 13, 2020 at 11:17:36AM -0700, Christoph Hellwig wrote:
> > > Can you also move kernel_read_* out of fs.h? That header gets pulled
> > > in just about everywhere and doesn't really need function not related
> > > to the general fs interface.
> >
> > Sure, where should I dump these?
>
> Maybe a new linux/kernel_read_file.h? Bonus points for a small top
> of the file comment explaining the point of the interface, which I
> still don't get :)
Instead of rolling your own method of having the kernel read a file,
which requires call specific security hooks, this interface provides a
single generic set of pre and post security hooks. The
kernel_read_file_id enumeration permits the security hook to
differentiate between callers.
To comply with secure and trusted boot concepts, a file cannot be
accessible to the caller until after it has been measured and/or the
integrity (hash/signature) appraised.
In some cases, the file was previously read twice, first to measure
and/or appraise the file and then read again into a buffer for
use. This interface reads the file into a buffer once, calls the
generic post security hook, before providing the buffer to the caller.
(Note using firmware pre-allocated memory might be an issue.)
Partial reading firmware will result in needing to pre-read the entire
file, most likely on the security pre hook.
Mimi
On Mon, May 18, 2020 at 08:37:42AM -0400, Mimi Zohar wrote:
> Hi Christoph,
>
> On Sun, 2020-05-17 at 23:22 -0700, Christoph Hellwig wrote:
> > On Fri, May 15, 2020 at 09:29:33PM +0000, Luis Chamberlain wrote:
> > > On Wed, May 13, 2020 at 11:17:36AM -0700, Christoph Hellwig wrote:
> > > > Can you also move kernel_read_* out of fs.h? That header gets pulled
> > > > in just about everywhere and doesn't really need function not related
> > > > to the general fs interface.
> > >
> > > Sure, where should I dump these?
> >
> > Maybe a new linux/kernel_read_file.h? Bonus points for a small top
> > of the file comment explaining the point of the interface, which I
> > still don't get :)
>
> Instead of rolling your own method of having the kernel read a file,
> which requires call specific security hooks, this interface provides a
> single generic set of pre and post security hooks.??The
> kernel_read_file_id enumeration permits the security hook to
> differentiate between callers.
>
> To comply with secure and trusted boot concepts, a file cannot be
> accessible to the caller until after it has been measured and/or the
> integrity (hash/signature) appraised.
>
> In some cases, the file was previously read twice, first to measure
> and/or appraise the file and then read again into a buffer for
> use.??This interface reads the file into a buffer once, calls the
> generic post security hook, before providing the buffer to the caller.
> ?(Note using firmware pre-allocated memory might be an issue.)
>
> Partial reading firmware will result in needing to pre-read the entire
> file, most likely on the security pre hook.
Well described! :)
--
Kees Cook
Hi Mimi,
On 2020-05-18 5:37 a.m., Mimi Zohar wrote:
> Hi Christoph,
>
> On Sun, 2020-05-17 at 23:22 -0700, Christoph Hellwig wrote:
>> On Fri, May 15, 2020 at 09:29:33PM +0000, Luis Chamberlain wrote:
>>> On Wed, May 13, 2020 at 11:17:36AM -0700, Christoph Hellwig wrote:
>>>> Can you also move kernel_read_* out of fs.h? That header gets pulled
>>>> in just about everywhere and doesn't really need function not related
>>>> to the general fs interface.
>>> Sure, where should I dump these?
>> Maybe a new linux/kernel_read_file.h? Bonus points for a small top
>> of the file comment explaining the point of the interface, which I
>> still don't get :)
> Instead of rolling your own method of having the kernel read a file,
> which requires call specific security hooks, this interface provides a
> single generic set of pre and post security hooks. The
> kernel_read_file_id enumeration permits the security hook to
> differentiate between callers.
>
> To comply with secure and trusted boot concepts, a file cannot be
> accessible to the caller until after it has been measured and/or the
> integrity (hash/signature) appraised.
>
> In some cases, the file was previously read twice, first to measure
> and/or appraise the file and then read again into a buffer for
> use. This interface reads the file into a buffer once, calls the
> generic post security hook, before providing the buffer to the caller.
> (Note using firmware pre-allocated memory might be an issue.)
>
> Partial reading firmware will result in needing to pre-read the entire
> file, most likely on the security pre hook.
The entire file may be very large and not fit into a buffer.
Hence one of the reasons for a partial read of the file.
For security purposes, you need to change your code to limit the amount
of data it reads into a buffer at one time to not consume or run out of
much memory.
>
> Mimi
Scott
On Fri, May 22, 2020 at 03:24:32PM -0700, Scott Branden wrote:
> On 2020-05-18 5:37 a.m., Mimi Zohar wrote:
> > On Sun, 2020-05-17 at 23:22 -0700, Christoph Hellwig wrote:
> > > On Fri, May 15, 2020 at 09:29:33PM +0000, Luis Chamberlain wrote:
> > > > On Wed, May 13, 2020 at 11:17:36AM -0700, Christoph Hellwig wrote:
> > > > > Can you also move kernel_read_* out of fs.h? That header gets pulled
> > > > > in just about everywhere and doesn't really need function not related
> > > > > to the general fs interface.
> > > > Sure, where should I dump these?
> > > Maybe a new linux/kernel_read_file.h? Bonus points for a small top
> > > of the file comment explaining the point of the interface, which I
> > > still don't get :)
> > Instead of rolling your own method of having the kernel read a file,
> > which requires call specific security hooks, this interface provides a
> > single generic set of pre and post security hooks.??The
> > kernel_read_file_id enumeration permits the security hook to
> > differentiate between callers.
> >
> > To comply with secure and trusted boot concepts, a file cannot be
> > accessible to the caller until after it has been measured and/or the
> > integrity (hash/signature) appraised.
> >
> > In some cases, the file was previously read twice, first to measure
> > and/or appraise the file and then read again into a buffer for
> > use.??This interface reads the file into a buffer once, calls the
> > generic post security hook, before providing the buffer to the caller.
> > ?(Note using firmware pre-allocated memory might be an issue.)
> >
> > Partial reading firmware will result in needing to pre-read the entire
> > file, most likely on the security pre hook.
> The entire file may be very large and not fit into a buffer.
> Hence one of the reasons for a partial read of the file.
> For security purposes, you need to change your code to limit the amount
> of data it reads into a buffer at one time to not consume or run out of much
> memory.
Hm? That's not how whole-file hashing works. :)
These hooks need to finish their hashing and policy checking before they
can allow the rest of the code to move forward. (That's why it's a
security hook.) If kernel memory utilization is the primary concern,
then sure, things could be rearranged to do partial read and update the
hash incrementally, but the entire file still needs to be locked,
entirely hashed by hook, then read by the caller, then unlocked and
released.
So, if you want to have partial file reads work, you'll need to
rearchitect the way this works to avoid regressing the security coverage
of these operations.
So, probably, the code will look something like:
file = kernel_open_file_for_reading(...)
file = open...
disallow_writes(file);
while (processed < size-of-file) {
buf = read(file, size...)
security_file_read_partial(buf)
}
ret = security_file_read_finished(file);
if (ret < 0) {
allow_writes(file);
return PTR_ERR(ret);
}
return file;
while (processed < size-of-file) {
buf = read(file, size...)
firmware_send_partial(buf);
}
kernel_close_file_for_reading(file)
allow_writes(file);
--
Kees Cook
Hi Kees,
On 2020-05-22 4:04 p.m., Kees Cook wrote:
> On Fri, May 22, 2020 at 03:24:32PM -0700, Scott Branden wrote:
>> On 2020-05-18 5:37 a.m., Mimi Zohar wrote:
>>> On Sun, 2020-05-17 at 23:22 -0700, Christoph Hellwig wrote:
>>>> On Fri, May 15, 2020 at 09:29:33PM +0000, Luis Chamberlain wrote:
>>>>> On Wed, May 13, 2020 at 11:17:36AM -0700, Christoph Hellwig wrote:
>>>>>> Can you also move kernel_read_* out of fs.h? That header gets pulled
>>>>>> in just about everywhere and doesn't really need function not related
>>>>>> to the general fs interface.
>>>>> Sure, where should I dump these?
>>>> Maybe a new linux/kernel_read_file.h? Bonus points for a small top
>>>> of the file comment explaining the point of the interface, which I
>>>> still don't get :)
>>> Instead of rolling your own method of having the kernel read a file,
>>> which requires call specific security hooks, this interface provides a
>>> single generic set of pre and post security hooks. The
>>> kernel_read_file_id enumeration permits the security hook to
>>> differentiate between callers.
>>>
>>> To comply with secure and trusted boot concepts, a file cannot be
>>> accessible to the caller until after it has been measured and/or the
>>> integrity (hash/signature) appraised.
>>>
>>> In some cases, the file was previously read twice, first to measure
>>> and/or appraise the file and then read again into a buffer for
>>> use. This interface reads the file into a buffer once, calls the
>>> generic post security hook, before providing the buffer to the caller.
>>> (Note using firmware pre-allocated memory might be an issue.)
>>>
>>> Partial reading firmware will result in needing to pre-read the entire
>>> file, most likely on the security pre hook.
>> The entire file may be very large and not fit into a buffer.
>> Hence one of the reasons for a partial read of the file.
>> For security purposes, you need to change your code to limit the amount
>> of data it reads into a buffer at one time to not consume or run out of much
>> memory.
> Hm? That's not how whole-file hashing works. :)
>
> These hooks need to finish their hashing and policy checking before they
> can allow the rest of the code to move forward. (That's why it's a
> security hook.) If kernel memory utilization is the primary concern,
> then sure, things could be rearranged to do partial read and update the
> hash incrementally, but the entire file still needs to be locked,
> entirely hashed by hook, then read by the caller, then unlocked and
> released.
>
> So, if you want to have partial file reads work, you'll need to
> rearchitect the way this works to avoid regressing the security coverage
> of these operations.
I am not familiar with how the security handling code works at all.
Is the same security check run on files opened from user space?
A file could be huge.
If it assumes there is there is enough memory available to read the
entire file into kernel space
then the improvement below can be left as a memory optimization to be
done in
an independent (or future) patch series.
> So, probably, the code will look something like:
>
>
> file = kernel_open_file_for_reading(...)
> file = open...
> disallow_writes(file);
> while (processed < size-of-file) {
> buf = read(file, size...)
> security_file_read_partial(buf)
> }
> ret = security_file_read_finished(file);
> if (ret < 0) {
> allow_writes(file);
> return PTR_ERR(ret);
> }
> return file;
>
> while (processed < size-of-file) {
> buf = read(file, size...)
> firmware_send_partial(buf);
> }
>
> kernel_close_file_for_reading(file)
> allow_writes(file);
>
>
On Fri, 2020-05-22 at 16:25 -0700, Scott Branden wrote:
> Hi Kees,
>
> On 2020-05-22 4:04 p.m., Kees Cook wrote:
> > On Fri, May 22, 2020 at 03:24:32PM -0700, Scott Branden wrote:
> >> On 2020-05-18 5:37 a.m., Mimi Zohar wrote:
> >>> On Sun, 2020-05-17 at 23:22 -0700, Christoph Hellwig wrote:
> >>>> On Fri, May 15, 2020 at 09:29:33PM +0000, Luis Chamberlain wrote:
> >>>>> On Wed, May 13, 2020 at 11:17:36AM -0700, Christoph Hellwig wrote:
> >>>>>> Can you also move kernel_read_* out of fs.h? That header gets pulled
> >>>>>> in just about everywhere and doesn't really need function not related
> >>>>>> to the general fs interface.
> >>>>> Sure, where should I dump these?
> >>>> Maybe a new linux/kernel_read_file.h? Bonus points for a small top
> >>>> of the file comment explaining the point of the interface, which I
> >>>> still don't get :)
> >>> Instead of rolling your own method of having the kernel read a file,
> >>> which requires call specific security hooks, this interface provides a
> >>> single generic set of pre and post security hooks. The
> >>> kernel_read_file_id enumeration permits the security hook to
> >>> differentiate between callers.
> >>>
> >>> To comply with secure and trusted boot concepts, a file cannot be
> >>> accessible to the caller until after it has been measured and/or the
> >>> integrity (hash/signature) appraised.
> >>>
> >>> In some cases, the file was previously read twice, first to measure
> >>> and/or appraise the file and then read again into a buffer for
> >>> use. This interface reads the file into a buffer once, calls the
> >>> generic post security hook, before providing the buffer to the caller.
> >>> (Note using firmware pre-allocated memory might be an issue.)
> >>>
> >>> Partial reading firmware will result in needing to pre-read the entire
> >>> file, most likely on the security pre hook.
> >> The entire file may be very large and not fit into a buffer.
> >> Hence one of the reasons for a partial read of the file.
> >> For security purposes, you need to change your code to limit the amount
> >> of data it reads into a buffer at one time to not consume or run out of much
> >> memory.
> > Hm? That's not how whole-file hashing works. :)
>
> >
> > These hooks need to finish their hashing and policy checking before they
> > can allow the rest of the code to move forward. (That's why it's a
> > security hook.) If kernel memory utilization is the primary concern,
> > then sure, things could be rearranged to do partial read and update the
> > hash incrementally, but the entire file still needs to be locked,
> > entirely hashed by hook, then read by the caller, then unlocked and
> > released.
Exactly.
> >
> > So, if you want to have partial file reads work, you'll need to
> > rearchitect the way this works to avoid regressing the security coverage
> > of these operations.
> I am not familiar with how the security handling code works at all.
> Is the same security check run on files opened from user space?
> A file could be huge.
>
> If it assumes there is there is enough memory available to read the
> entire file into kernel space then the improvement below can be left as
> a memory optimization to be done in an independent (or future) patch series.
There are two security hooks - security_kernel_read_file(),
security_kernel_post_read_file - in kernel_read_file(). The first
hook is called before the file is read into a buffer, while the second
hook is called afterwards.
For partial reads, measuring the firmware and verifying the firmware's
signature will need to be done on the security_kernel_read_file()
hook.
>
> > So, probably, the code will look something like:
> >
> >
> > file = kernel_open_file_for_reading(...)
> > file = open...
> > disallow_writes(file);
> > while (processed < size-of-file) {
> > buf = read(file, size...)
> > security_file_read_partial(buf)
> > }
> > ret = security_file_read_finished(file);
> > if (ret < 0) {
> > allow_writes(file);
> > return PTR_ERR(ret);
> > }
> > return file;
> >
> > while (processed < size-of-file) {
> > buf = read(file, size...)
> > firmware_send_partial(buf);
> > }
> >
> > kernel_close_file_for_reading(file)
> > allow_writes(file);
Right, the ima_file_mmap(), ima_bprm_check(), and ima_file_check()
hooks call process_measurement() to do this. ima_post_read_file()
passes a buffer to process_measurement() instead.
Scott, the change should be straight forward. The additional patch
needs to:
- define a new kernel_read_file_id enumeration, like
FIRMWARE_PARTIAL_READ.
- Currently ima_read_file() has a comment about pre-allocated firmware
buffers. Update ima_read_file() to call process_measurement() for the
new enumeration FIRMWARE_PARTIAL_READ and update ima_post_read_file()
to return immediately.
The built-in IMA measurement policy contains a rule to measure
firmware. The policy can be specified on the boot command line by
specifying "ima_policy=tcb". After reading the firmware, the firmware
measurement should be in <securityfs>/ima/ascii_runtime_measurements.
thanks,
Mimi
Hi Mimi,
On 2020-05-23 7:52 p.m., Mimi Zohar wrote:
> On Fri, 2020-05-22 at 16:25 -0700, Scott Branden wrote:
>> Hi Kees,
>>
>> On 2020-05-22 4:04 p.m., Kees Cook wrote:
>>> On Fri, May 22, 2020 at 03:24:32PM -0700, Scott Branden wrote:
>>>> On 2020-05-18 5:37 a.m., Mimi Zohar wrote:
>>>>> On Sun, 2020-05-17 at 23:22 -0700, Christoph Hellwig wrote:
>>>>>> On Fri, May 15, 2020 at 09:29:33PM +0000, Luis Chamberlain wrote:
>>>>>>> On Wed, May 13, 2020 at 11:17:36AM -0700, Christoph Hellwig wrote:
>>>>>>>> Can you also move kernel_read_* out of fs.h? That header gets pulled
>>>>>>>> in just about everywhere and doesn't really need function not related
>>>>>>>> to the general fs interface.
>>>>>>> Sure, where should I dump these?
>>>>>> Maybe a new linux/kernel_read_file.h? Bonus points for a small top
>>>>>> of the file comment explaining the point of the interface, which I
>>>>>> still don't get :)
>>>>> Instead of rolling your own method of having the kernel read a file,
>>>>> which requires call specific security hooks, this interface provides a
>>>>> single generic set of pre and post security hooks. The
>>>>> kernel_read_file_id enumeration permits the security hook to
>>>>> differentiate between callers.
>>>>>
>>>>> To comply with secure and trusted boot concepts, a file cannot be
>>>>> accessible to the caller until after it has been measured and/or the
>>>>> integrity (hash/signature) appraised.
>>>>>
>>>>> In some cases, the file was previously read twice, first to measure
>>>>> and/or appraise the file and then read again into a buffer for
>>>>> use. This interface reads the file into a buffer once, calls the
>>>>> generic post security hook, before providing the buffer to the caller.
>>>>> (Note using firmware pre-allocated memory might be an issue.)
>>>>>
>>>>> Partial reading firmware will result in needing to pre-read the entire
>>>>> file, most likely on the security pre hook.
>>>> The entire file may be very large and not fit into a buffer.
>>>> Hence one of the reasons for a partial read of the file.
>>>> For security purposes, you need to change your code to limit the amount
>>>> of data it reads into a buffer at one time to not consume or run out of much
>>>> memory.
>>> Hm? That's not how whole-file hashing works. :)
>>> These hooks need to finish their hashing and policy checking before they
>>> can allow the rest of the code to move forward. (That's why it's a
>>> security hook.) If kernel memory utilization is the primary concern,
>>> then sure, things could be rearranged to do partial read and update the
>>> hash incrementally, but the entire file still needs to be locked,
>>> entirely hashed by hook, then read by the caller, then unlocked and
>>> released.
> Exactly.
>
>>> So, if you want to have partial file reads work, you'll need to
>>> rearchitect the way this works to avoid regressing the security coverage
>>> of these operations.
>> I am not familiar with how the security handling code works at all.
>> Is the same security check run on files opened from user space?
>> A file could be huge.
>>
>> If it assumes there is there is enough memory available to read the
>> entire file into kernel space then the improvement below can be left as
>> a memory optimization to be done in an independent (or future) patch series.
> There are two security hooks - security_kernel_read_file(),
> security_kernel_post_read_file - in kernel_read_file(). The first
> hook is called before the file is read into a buffer, while the second
> hook is called afterwards.
>
> For partial reads, measuring the firmware and verifying the firmware's
> signature will need to be done on the security_kernel_read_file()
> hook.
>
>>> So, probably, the code will look something like:
>>>
>>>
>>> file = kernel_open_file_for_reading(...)
>>> file = open...
>>> disallow_writes(file);
>>> while (processed < size-of-file) {
>>> buf = read(file, size...)
>>> security_file_read_partial(buf)
>>> }
>>> ret = security_file_read_finished(file);
>>> if (ret < 0) {
>>> allow_writes(file);
>>> return PTR_ERR(ret);
>>> }
>>> return file;
>>>
>>> while (processed < size-of-file) {
>>> buf = read(file, size...)
>>> firmware_send_partial(buf);
>>> }
>>>
>>> kernel_close_file_for_reading(file)
>>> allow_writes(file);
> Right, the ima_file_mmap(), ima_bprm_check(), and ima_file_check()
> hooks call process_measurement() to do this. ima_post_read_file()
> passes a buffer to process_measurement() instead.
>
> Scott, the change should be straight forward. The additional patch
> needs to:
> - define a new kernel_read_file_id enumeration, like
> FIRMWARE_PARTIAL_READ.
> - Currently ima_read_file() has a comment about pre-allocated firmware
> buffers. Update ima_read_file() to call process_measurement() for the
> new enumeration FIRMWARE_PARTIAL_READ and update ima_post_read_file()
> to return immediately.
Should this be what is in ima_read_file?
{
enum ima_hooks func;
u32 secid;
if (read_id != READING_FIRMWARE_PARTIAL_READ)
return 0;
if (!file) { /* should never happen */
if (ima_appraise & IMA_APPRAISE_ENFORCE)
return -EACCES;
return 0;
}
security_task_getsecid(current, &secid);
return process_measurement(file, current_cred(), secid, NULL,
0, MAY_READ, FILE_CHECK);
}
>
> The built-in IMA measurement policy contains a rule to measure
> firmware. The policy can be specified on the boot command line by
> specifying "ima_policy=tcb". After reading the firmware, the firmware
> measurement should be in <securityfs>/ima/ascii_runtime_measurements.
>
> thanks,
>
> Mimi
On Fri, 2020-06-05 at 11:15 -0700, Scott Branden wrote:
> Hi Mimi,
>
> On 2020-05-23 7:52 p.m., Mimi Zohar wrote:
> > Scott, the change should be straight forward. The additional patch
> > needs to:
> > - define a new kernel_read_file_id enumeration, like
> > FIRMWARE_PARTIAL_READ.
> > - Currently ima_read_file() has a comment about pre-allocated firmware
> > buffers. Update ima_read_file() to call process_measurement() for the
> > new enumeration FIRMWARE_PARTIAL_READ and update ima_post_read_file()
> > to return immediately.
> Should this be what is in ima_read_file?
> {
> enum ima_hooks func;
> u32 secid;
Please don't remove the existing comment.
> if (read_id != READING_FIRMWARE_PARTIAL_READ)
> return 0;
>
> if (!file) { /* should never happen */
> if (ima_appraise & IMA_APPRAISE_ENFORCE)
> return -EACCES;
> return 0;
> }
This checks for any IMA appraise rule. You want to enforce firmware
signature checking only if there is a firmware appraise rule. Refer
to ima_post_read_file().
> security_task_getsecid(current, &secid);
> return process_measurement(file, current_cred(), secid, NULL,
> 0, MAY_READ, FILE_CHECK);
The read_idmap enumeration should be updated similar to the other
firmware. Keep the code generic. Refer to ima_post_read_file().
func will be defined as FIRMWARE_CHECK.
thanks,
Mimi
On Mon, May 18, 2020 at 08:21:08AM -0700, Kees Cook wrote:
> On Mon, May 18, 2020 at 08:37:42AM -0400, Mimi Zohar wrote:
> > Hi Christoph,
> >
> > On Sun, 2020-05-17 at 23:22 -0700, Christoph Hellwig wrote:
> > > On Fri, May 15, 2020 at 09:29:33PM +0000, Luis Chamberlain wrote:
> > > > On Wed, May 13, 2020 at 11:17:36AM -0700, Christoph Hellwig wrote:
> > > > > Can you also move kernel_read_* out of fs.h? That header gets pulled
> > > > > in just about everywhere and doesn't really need function not related
> > > > > to the general fs interface.
> > > >
> > > > Sure, where should I dump these?
> > >
> > > Maybe a new linux/kernel_read_file.h? Bonus points for a small top
> > > of the file comment explaining the point of the interface, which I
> > > still don't get :)
> >
> > Instead of rolling your own method of having the kernel read a file,
> > which requires call specific security hooks, this interface provides a
> > single generic set of pre and post security hooks.??The
> > kernel_read_file_id enumeration permits the security hook to
> > differentiate between callers.
> >
> > To comply with secure and trusted boot concepts, a file cannot be
> > accessible to the caller until after it has been measured and/or the
> > integrity (hash/signature) appraised.
> >
> > In some cases, the file was previously read twice, first to measure
> > and/or appraise the file and then read again into a buffer for
> > use.??This interface reads the file into a buffer once, calls the
> > generic post security hook, before providing the buffer to the caller.
> > ?(Note using firmware pre-allocated memory might be an issue.)
> >
> > Partial reading firmware will result in needing to pre-read the entire
> > file, most likely on the security pre hook.
>
> Well described! :)
Since you're moving all this stuff, it woudl be good if you can add this
as part of new kdoc as well.
Luis