* Re: Should mprotect(..., PROT_EXEC) be checked by IMA?
From: Matthew Garrett @ 2019-04-02 22:31 UTC (permalink / raw)
To: Igor Zhbanov
Cc: Stephen Smalley, Mimi Zohar, Kees Cook, Casey Schaufler,
Paul Moore, John Johansen, linux-integrity, Jann Horn,
linux-security-module
In-Reply-To: <cb46d5ba-30de-664f-67d4-646da4592a6f@omprussia.ru>
On Fri, Mar 29, 2019 at 5:50 AM Igor Zhbanov <i.zhbanov@omprussia.ru> wrote:
> I want to be sure that no unsigned code page could be executed. So exploits
> could only be of ROP kind and not being able to download any extra code
> from their servers. That's why I found that disabling of anonymous executable
> pages could be useful for that (as well as disabling of making executable
> pages writable to modify already mapped code). In conjunction with IMA it
> should guarantee that no untrusted code could be executed.
Remember that many interpreted languages allow execution of code
provided to them on the command line (eg, python -c) and also grant
access to arbitrary syscalls, so there's still no guarantee that
you're only executing trusted code.
^ permalink raw reply
* [PATCH 1/2] efi: Fix cast to pointer from integer of different size in TPM log code
From: Matthew Garrett @ 2019-04-02 21:55 UTC (permalink / raw)
To: linux-integrity
Cc: peterhuewe, jarkko.sakkinen, jgg, roberto.sassu, linux-efi,
linux-security-module, linux-kernel, tweek, Matthew Garrett,
Matthew Garrett
In-Reply-To: <20190402215556.257406-1-matthewgarrett@google.com>
8bfcff4a6a1d9d7226bb63a7da758b82d9ab4373 introduced a cast from
efi_physical_address_t to (void *), which are different sizes on 32-bit.
Fix that. Caught by the 0-day test bot.
Signed-off-by: Matthew Garrett <mjg59@google.com>
---
drivers/firmware/efi/libstub/tpm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/firmware/efi/libstub/tpm.c b/drivers/firmware/efi/libstub/tpm.c
index b6e93e14fcf1..6b3b507a54eb 100644
--- a/drivers/firmware/efi/libstub/tpm.c
+++ b/drivers/firmware/efi/libstub/tpm.c
@@ -114,8 +114,8 @@ void efi_retrieve_tpm2_eventlog(efi_system_table_t *sys_table_arg)
*/
last_entry_size =
__calc_tpm2_event_size((void *)last_entry_addr,
- (void *)log_location,
- false);
+ (void *)(long)log_location,
+ false);
} else {
last_entry_size = sizeof(struct tcpa_event) +
((struct tcpa_event *) last_entry_addr)->event_size;
--
2.21.0.392.gf8f6787159e-goog
^ permalink raw reply related
* [PATCH 2/2] tpm: Fix builds on platforms that lack early_memremap()
From: Matthew Garrett @ 2019-04-02 21:55 UTC (permalink / raw)
To: linux-integrity
Cc: peterhuewe, jarkko.sakkinen, jgg, roberto.sassu, linux-efi,
linux-security-module, linux-kernel, tweek, Matthew Garrett,
Matthew Garrett
In-Reply-To: <20190402215556.257406-1-matthewgarrett@google.com>
On EFI systems, __calc_tpm2_event_size() needs to be able to map tables
at early boot time in order to extract information from them.
Unfortunately this interacts badly with other architectures that don't
provide the early_memremap() interface but which may still have other
mechanisms for obtaining crypto-agile logs. Abstract this away so we
can avoid the need for two implementations while still avoiding breakage
on architectures that don't require remapping of the table.
Signed-off-by: Matthew Garrett <mjg59@google.com>
---
drivers/firmware/efi/tpm.c | 3 +++
include/linux/tpm_eventlog.h | 32 ++++++++++++++++++++------------
2 files changed, 23 insertions(+), 12 deletions(-)
diff --git a/drivers/firmware/efi/tpm.c b/drivers/firmware/efi/tpm.c
index f2a13cbb8688..fe48150f06d1 100644
--- a/drivers/firmware/efi/tpm.c
+++ b/drivers/firmware/efi/tpm.c
@@ -4,6 +4,9 @@
* Thiebaud Weksteen <tweek@google.com>
*/
+#define TPM_MEMREMAP(start, size) early_memremap(start, size)
+#define TPM_MEMUNMAP(start, size) early_memunmap(start, size)
+
#include <linux/efi.h>
#include <linux/init.h>
#include <linux/memblock.h>
diff --git a/include/linux/tpm_eventlog.h b/include/linux/tpm_eventlog.h
index d889e12047d9..0ca27bc053af 100644
--- a/include/linux/tpm_eventlog.h
+++ b/include/linux/tpm_eventlog.h
@@ -128,6 +128,14 @@ struct tcg_algorithm_info {
struct tcg_algorithm_size digest_sizes[];
};
+#ifndef TPM_MEMREMAP
+#define TPM_MEMREMAP(start, size) NULL
+#endif
+
+#ifndef TPM_MEMUNMAP
+#define TPM_MEMUNMAP(start, size) do{} while(0)
+#endif
+
/**
* __calc_tpm2_event_size - calculate the size of a TPM2 event log entry
* @event: Pointer to the event whose size should be calculated
@@ -171,8 +179,8 @@ static inline int __calc_tpm2_event_size(struct tcg_pcr_event2_head *event,
/* Map the event header */
if (do_mapping) {
mapping_size = marker - marker_start;
- mapping = early_memremap((unsigned long)marker_start,
- mapping_size);
+ mapping = TPM_MEMREMAP((unsigned long)marker_start,
+ mapping_size);
if (!mapping) {
size = 0;
goto out;
@@ -192,10 +200,10 @@ static inline int __calc_tpm2_event_size(struct tcg_pcr_event2_head *event,
/* Map the digest's algorithm identifier */
if (do_mapping) {
- early_memunmap(mapping, mapping_size);
+ TPM_MEMUNMAP(mapping, mapping_size);
mapping_size = marker - marker_start + halg_size;
- mapping = early_memremap((unsigned long)marker_start,
- mapping_size);
+ mapping = TPM_MEMREMAP((unsigned long)marker_start,
+ mapping_size);
if (!mapping) {
size = 0;
goto out;
@@ -212,10 +220,10 @@ static inline int __calc_tpm2_event_size(struct tcg_pcr_event2_head *event,
/* Map the digest content itself */
if (do_mapping) {
- early_memunmap(mapping, mapping_size);
+ TPM_MEMUNMAP(mapping, mapping_size);
mapping_size = marker - marker_start;
- mapping = early_memremap((unsigned long)marker_start,
- mapping_size);
+ mapping = TPM_MEMREMAP((unsigned long)marker_start,
+ mapping_size);
if (!mapping) {
size = 0;
goto out;
@@ -238,10 +246,10 @@ static inline int __calc_tpm2_event_size(struct tcg_pcr_event2_head *event,
* we don't need to map it
*/
if (do_mapping) {
- early_memunmap(marker_start, mapping_size);
+ TPM_MEMUNMAP(marker_start, mapping_size);
mapping_size += sizeof(event_field->event_size);
- mapping = early_memremap((unsigned long)marker_start,
- mapping_size);
+ mapping = TPM_MEMREMAP((unsigned long)marker_start,
+ mapping_size);
if (!mapping) {
size = 0;
goto out;
@@ -256,7 +264,7 @@ static inline int __calc_tpm2_event_size(struct tcg_pcr_event2_head *event,
size = 0;
out:
if (do_mapping)
- early_memunmap(mapping, mapping_size);
+ TPM_MEMUNMAP(mapping, mapping_size);
return size;
}
--
2.21.0.392.gf8f6787159e-goog
^ permalink raw reply related
* [PATCH] TCG2 log support build fixes for non-x86_64
From: Matthew Garrett @ 2019-04-02 21:55 UTC (permalink / raw)
To: linux-integrity
Cc: peterhuewe, jarkko.sakkinen, jgg, roberto.sassu, linux-efi,
linux-security-module, linux-kernel, tweek
Couple of patches to fix ktest reported issues with the crypto-agile log
format support.
^ permalink raw reply
* Re: Add support for TCG2 log format on UEFI systems
From: Matthew Garrett @ 2019-04-02 17:15 UTC (permalink / raw)
To: Jarkko Sakkinen
Cc: tomas.winkler, linux-integrity, Peter Huewe, Jason Gunthorpe,
Roberto Sassu, linux-efi, LSM List, Linux Kernel Mailing List,
Thiébaud Weksteen
In-Reply-To: <20190402130704.GA3916@linux.intel.com>
On Tue, Apr 2, 2019 at 6:07 AM Jarkko Sakkinen
<jarkko.sakkinen@linux.intel.com> wrote:
> Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> Tested-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
>
> I'll apply all patches soonish and include them to the next PR.
Thanks! Looks like I need some fixes to deal with non-x86
architectures, I'll get on that today.
^ permalink raw reply
* Re: Add support for TCG2 log format on UEFI systems
From: Jarkko Sakkinen @ 2019-04-02 13:07 UTC (permalink / raw)
To: Matthew Garrett
Cc: tomas.winkler, linux-integrity, Peter Huewe, Jason Gunthorpe,
Roberto Sassu, linux-efi, LSM List, Linux Kernel Mailing List,
Thiébaud Weksteen
In-Reply-To: <CACdnJutCC7n++Nz5qy1YzmsSchEApDUvMH9-qpxYXckh-Dzf-Q@mail.gmail.com>
On Mon, Apr 01, 2019 at 08:32:26PM -0700, Matthew Garrett wrote:
> On Mon, Apr 1, 2019 at 4:52 PM Jarkko Sakkinen
> <jarkko.sakkinen@linux.intel.com> wrote:
> >
> > On Wed, Feb 27, 2019 at 12:26:54PM -0800, Matthew Garrett wrote:
> > > Identical to V4, but based on tpmdd-next
> >
> > OK, so on my GLK NUC I get valid final log and invalid event log
> > after adding some extra klogs.
> >
> > I.e.
> >
> > - if (efi.tpm_log == EFI_INVALID_TABLE_ADDR)
> > + if (efi.tpm_log == EFI_INVALID_TABLE_ADDR) {
>
> Just to make sure - are you booting via the EFI boot stub? We need to
> obtain the boot log before ExitBootServices() is called, so if you're
> booting directly into the 32-bit entry point (eg, by using the "linux"
> command in grub) then you won't get a log.
... and I was wondering why it used to work when I tested the first
flush of patches. Ugh, sorry. The only excuse is too much multitasking
lately.
Anyway:
Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Tested-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
I'll apply all patches soonish and include them to the next PR.
/Jarkko
^ permalink raw reply
* Re: Add support for TCG2 log format on UEFI systems
From: Matthew Garrett @ 2019-04-02 3:32 UTC (permalink / raw)
To: Jarkko Sakkinen
Cc: tomas.winkler, linux-integrity, Peter Huewe, Jason Gunthorpe,
Roberto Sassu, linux-efi, LSM List, Linux Kernel Mailing List,
Thiébaud Weksteen
In-Reply-To: <20190401235245.GA29282@linux.intel.com>
On Mon, Apr 1, 2019 at 4:52 PM Jarkko Sakkinen
<jarkko.sakkinen@linux.intel.com> wrote:
>
> On Wed, Feb 27, 2019 at 12:26:54PM -0800, Matthew Garrett wrote:
> > Identical to V4, but based on tpmdd-next
>
> OK, so on my GLK NUC I get valid final log and invalid event log
> after adding some extra klogs.
>
> I.e.
>
> - if (efi.tpm_log == EFI_INVALID_TABLE_ADDR)
> + if (efi.tpm_log == EFI_INVALID_TABLE_ADDR) {
Just to make sure - are you booting via the EFI boot stub? We need to
obtain the boot log before ExitBootServices() is called, so if you're
booting directly into the 32-bit entry point (eg, by using the "linux"
command in grub) then you won't get a log.
^ permalink raw reply
* Re: Add support for TCG2 log format on UEFI systems
From: Jarkko Sakkinen @ 2019-04-01 23:52 UTC (permalink / raw)
To: Matthew Garrett, tomas.winkler
Cc: linux-integrity, peterhuewe, jgg, roberto.sassu, linux-efi,
linux-security-module, linux-kernel, tweek
In-Reply-To: <20190227202658.197113-1-matthewgarrett@google.com>
On Wed, Feb 27, 2019 at 12:26:54PM -0800, Matthew Garrett wrote:
> Identical to V4, but based on tpmdd-next
OK, so on my GLK NUC I get valid final log and invalid event log
after adding some extra klogs.
I.e.
- if (efi.tpm_log == EFI_INVALID_TABLE_ADDR)
+ if (efi.tpm_log == EFI_INVALID_TABLE_ADDR) {
+ pr_err("No event log\n");
return -ENODEV;
+ }
will result
[ 2.654392] No event log
but still
[ 0.000000] efi: ACPI 2.0=0x69ca2000 ACPI=0x69ca2000 TPMFinalLog=0x69ce4000 SMBIOS=0x69f63000 SMBIOS 3.0=0x69f62000 ESRT=0x69f3e818 MEMATTR=0x63475118
Tomas, I wonder if you are able to get the log out with some machine?
/Jarkko
^ permalink raw reply
* Re: [GIT PULL] tpmdd fixes for Linux v5.1
From: Jarkko Sakkinen @ 2019-04-01 10:02 UTC (permalink / raw)
To: James Morris; +Cc: linux-kernel, linux-security-module, linux-integrity
In-Reply-To: <alpine.LRH.2.21.1903300540530.2240@namei.org>
On Sat, Mar 30, 2019 at 05:41:19AM +1100, James Morris wrote:
> On Fri, 29 Mar 2019, Jarkko Sakkinen wrote:
>
> > Hi James,
> >
> > These are critical fixes for v5.1. Contains also couple of new selftests for
> > v5.1 features (partial reads in /dev/tpm0). I hope these could still reach
> > the release. Thanks.
>
> Applied to
> git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next-tpm
Thank you.
/Jarkko
^ permalink raw reply
* Re: [GIT PULL][UPDATED] security: yama and LSM config fixes
From: pr-tracker-bot @ 2019-03-30 17:30 UTC (permalink / raw)
To: James Morris; +Cc: Linus Torvalds, linux-security-module, linux-kernel
In-Reply-To: <alpine.LRH.2.21.1903300811170.5953@namei.org>
The pull request you sent on Sat, 30 Mar 2019 08:12:07 +1100 (AEDT):
> git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git fixes-v5.1-a
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/12195302ee6c32cf3c0fa947e17303ce583d41c9
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
^ permalink raw reply
* Re: [GIT PULL] security: yama fix for v5.1
From: pr-tracker-bot @ 2019-03-30 17:30 UTC (permalink / raw)
To: James Morris; +Cc: Linus Torvalds, linux-security-module, linux-kernel
In-Reply-To: <alpine.LRH.2.21.1903300509370.689@namei.org>
The pull request you sent on Sat, 30 Mar 2019 05:10:48 +1100 (AEDT):
> git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git fixes-v5.1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/2623c4fbe2ad1341ff2d1e12410d0afdae2490ca
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
^ permalink raw reply
* Re: [PATCH 1/2] efi: add a function for transferring status to string
From: joeyli @ 2019-03-30 5:41 UTC (permalink / raw)
To: Mimi Zohar
Cc: Ard Biesheuvel, Lee, Chun-Yi, James Morris, Serge E . Hallyn,
David Howells, Josh Boyer, Nayna Jain, linux-efi,
linux-security-module, Linux Kernel Mailing List, Kees Cook,
Anton Vorontsov, Colin Cross, Tony Luck
In-Reply-To: <1553713442.4608.20.camel@linux.ibm.com>
Hi Mimi,
On Wed, Mar 27, 2019 at 03:04:02PM -0400, Mimi Zohar wrote:
> On Wed, 2019-03-27 at 19:58 +0100, Ard Biesheuvel wrote:
> > On Sun, 24 Mar 2019 at 01:26, Lee, Chun-Yi <joeyli.kernel@gmail.com> wrote:
> > >
> > > This function can be used to transfer EFI status code to string
> > > for printing out debug message. Using this function can improve
> > > the readability of log.
>
> Maybe instead of "for transferring status" use "to convert the status
> value to a" in the Subject line and here in the patch description.
>
Thanks for your suggestion. I will change subject and description.
> > >
> > > Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> > > Cc: Kees Cook <keescook@chromium.org>
> > > Cc: Anton Vorontsov <anton@enomsg.org>
> > > Cc: Colin Cross <ccross@android.com>
> > > Cc: Tony Luck <tony.luck@intel.com>
> > > Signed-off-by: "Lee, Chun-Yi" <jlee@suse.com>
> > > ---
> > > include/linux/efi.h | 28 ++++++++++++++++++++++++++++
> > > 1 file changed, 28 insertions(+)
> > >
> > > diff --git a/include/linux/efi.h b/include/linux/efi.h
> > > index 54357a258b35..a43cb0dc37af 100644
> > > --- a/include/linux/efi.h
> > > +++ b/include/linux/efi.h
> > > @@ -1768,4 +1768,32 @@ struct linux_efi_memreserve {
> > > #define EFI_MEMRESERVE_COUNT(size) (((size) - sizeof(struct linux_efi_memreserve)) \
> > > / sizeof(((struct linux_efi_memreserve *)0)->entry[0]))
> > >
> > > +#define EFI_STATUS_STR(_status) \
> > > +case EFI_##_status: \
> > > + return "EFI_" __stringify(_status);
> > > +
> > > +static inline char *
> > > +efi_status_to_str(efi_status_t status)
> > > +{
> > > + switch (status) {
> > > + EFI_STATUS_STR(SUCCESS)
> > > + EFI_STATUS_STR(LOAD_ERROR)
> > > + EFI_STATUS_STR(INVALID_PARAMETER)
> > > + EFI_STATUS_STR(UNSUPPORTED)
> > > + EFI_STATUS_STR(BAD_BUFFER_SIZE)
> > > + EFI_STATUS_STR(BUFFER_TOO_SMALL)
> > > + EFI_STATUS_STR(NOT_READY)
> > > + EFI_STATUS_STR(DEVICE_ERROR)
> > > + EFI_STATUS_STR(WRITE_PROTECTED)
> > > + EFI_STATUS_STR(OUT_OF_RESOURCES)
> > > + EFI_STATUS_STR(NOT_FOUND)
> > > + EFI_STATUS_STR(ABORTED)
> > > + EFI_STATUS_STR(SECURITY_VIOLATION)
> > > + default:
> > > + pr_warn("Unknown efi status: 0x%lx", status);
> > > + }
> > > +
> > > + return "Unknown efi status";
> > > +}
> > > +
> > > #endif /* _LINUX_EFI_H */
> > > --
> > > 2.16.4
> > >
> >
> > Please turn this into a proper function so that not every calling
> > object has to duplicate all these strings.
>
> Hi Ard,
>
> Keeping the status values and strings in sync is difficult. I was
> going to suggest moving the macro immediately after the status value
> definitions.
>
I will move the code to after the status value definitions.
Thanks
Joey Lee
^ permalink raw reply
* Re: [PATCH 1/2] efi: add a function for transferring status to string
From: joeyli @ 2019-03-30 5:37 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Lee, Chun-Yi, James Morris, Serge E . Hallyn, David Howells,
Josh Boyer, Nayna Jain, Mimi Zohar, linux-efi,
linux-security-module, Linux Kernel Mailing List, Kees Cook,
Anton Vorontsov, Colin Cross, Tony Luck
In-Reply-To: <CAKv+Gu9B6h3zGVTctepd1GE5LaaMaT5x14Le1v05AOhbH36bpQ@mail.gmail.com>
Hi Ard,
On Wed, Mar 27, 2019 at 07:58:03PM +0100, Ard Biesheuvel wrote:
> On Sun, 24 Mar 2019 at 01:26, Lee, Chun-Yi <joeyli.kernel@gmail.com> wrote:
> >
> > This function can be used to transfer EFI status code to string
> > for printing out debug message. Using this function can improve
> > the readability of log.
> >
> > Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> > Cc: Kees Cook <keescook@chromium.org>
> > Cc: Anton Vorontsov <anton@enomsg.org>
> > Cc: Colin Cross <ccross@android.com>
> > Cc: Tony Luck <tony.luck@intel.com>
> > Signed-off-by: "Lee, Chun-Yi" <jlee@suse.com>
> > ---
> > include/linux/efi.h | 28 ++++++++++++++++++++++++++++
> > 1 file changed, 28 insertions(+)
> >
> > diff --git a/include/linux/efi.h b/include/linux/efi.h
> > index 54357a258b35..a43cb0dc37af 100644
> > --- a/include/linux/efi.h
> > +++ b/include/linux/efi.h
> > @@ -1768,4 +1768,32 @@ struct linux_efi_memreserve {
> > #define EFI_MEMRESERVE_COUNT(size) (((size) - sizeof(struct linux_efi_memreserve)) \
> > / sizeof(((struct linux_efi_memreserve *)0)->entry[0]))
> >
> > +#define EFI_STATUS_STR(_status) \
> > +case EFI_##_status: \
> > + return "EFI_" __stringify(_status);
> > +
> > +static inline char *
> > +efi_status_to_str(efi_status_t status)
> > +{
> > + switch (status) {
> > + EFI_STATUS_STR(SUCCESS)
> > + EFI_STATUS_STR(LOAD_ERROR)
> > + EFI_STATUS_STR(INVALID_PARAMETER)
> > + EFI_STATUS_STR(UNSUPPORTED)
> > + EFI_STATUS_STR(BAD_BUFFER_SIZE)
> > + EFI_STATUS_STR(BUFFER_TOO_SMALL)
> > + EFI_STATUS_STR(NOT_READY)
> > + EFI_STATUS_STR(DEVICE_ERROR)
> > + EFI_STATUS_STR(WRITE_PROTECTED)
> > + EFI_STATUS_STR(OUT_OF_RESOURCES)
> > + EFI_STATUS_STR(NOT_FOUND)
> > + EFI_STATUS_STR(ABORTED)
> > + EFI_STATUS_STR(SECURITY_VIOLATION)
> > + default:
> > + pr_warn("Unknown efi status: 0x%lx", status);
> > + }
> > +
> > + return "Unknown efi status";
> > +}
> > +
> > #endif /* _LINUX_EFI_H */
> > --
> > 2.16.4
> >
>
> Please turn this into a proper function so that not every calling
> object has to duplicate all these strings.
OK! I will move them to function.
Thanks for your review!
Joey Lee
^ permalink raw reply
* Re: [PATCH] LSM: Revive CONFIG_DEFAULT_SECURITY_* for "make oldconfig"
From: Tetsuo Handa @ 2019-03-29 23:51 UTC (permalink / raw)
To: Kees Cook
Cc: James Morris, Jakub Kicinski, Randy Dunlap, linux-security-module,
linux-kernel
In-Reply-To: <20190329193604.GA30908@beast>
On 2019/03/30 4:36, Kees Cook wrote:
> Note that since TOMOYO can be fully stacked against the other legacy
> major LSMs, when it is selected, it explicitly disables the other LSMs
> to avoid them also initializing since TOMOYO does not expect this
> currently.
Excuse me, but isn't this exception confusing, for DEFAULT_SECURITY_TOMOYO
and DEFAULT_SECURITY_DAC are "opt-in" whereas DEFAULT_SECURITY_SELINUX and
DEFAULT_SECURITY_SMACK and DEFAULT_SECURITY_APPARMOR are "opt-out" ?
If SELinux/Smack/AppArmor people think this mixture is fine, I'm fine though...
> config LSM
> string "Ordered list of enabled LSMs"
> + default "yama,loadpin,safesetid,integrity,smack,selinux,tomoyo,apparmor" if DEFAULT_SECURITY_SMACK
> + default "yama,loadpin,safesetid,integrity,apparmor,selinux,smack,tomoyo" if DEFAULT_SECURITY_APPARMOR
> + default "yama,loadpin,safesetid,integrity,tomoyo" if DEFAULT_SECURITY_TOMOYO
> + default "yama,loadpin,safesetid,integrity" if DEFAULT_SECURITY_DAC
> default "yama,loadpin,safesetid,integrity,selinux,smack,tomoyo,apparmor"
> help
> A comma-separated list of LSMs, in initialization order.
>
^ permalink raw reply
* [GIT PULL][UPDATED] security: yama and LSM config fixes
From: James Morris @ 2019-03-29 21:12 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-security-module, linux-kernel
In-Reply-To: <alpine.LRH.2.21.1903300509370.689@namei.org>
Please pull these fixes for v5.1.
The following changes since commit 8c7ae38d1ce12a0eaeba655df8562552b3596c7f:
afs: Fix StoreData op marshalling (2019-03-28 08:54:20 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git fixes-v5.1-a
for you to fetch changes up to 2623c4fbe2ad1341ff2d1e12410d0afdae2490ca:
LSM: Revive CONFIG_DEFAULT_SECURITY_* for "make oldconfig" (2019-03-29 14:08:49 -0700)
----------------------------------------------------------------
Jann Horn (1):
Yama: mark local symbols as static
Kees Cook (1):
LSM: Revive CONFIG_DEFAULT_SECURITY_* for "make oldconfig"
security/Kconfig | 38 ++++++++++++++++++++++++++++++++++++++
security/yama/yama_lsm.c | 8 ++++----
2 files changed, 42 insertions(+), 4 deletions(-)
^ permalink raw reply
* Re: [PATCH v5 1/2] LSM: SafeSetID: gate setgid transitions
From: Casey Schaufler @ 2019-03-29 19:44 UTC (permalink / raw)
To: James Morris, Micah Morton; +Cc: serge, keescook, sds, linux-security-module
In-Reply-To: <alpine.LRH.2.21.1903300505540.689@namei.org>
On 3/29/2019 11:06 AM, James Morris wrote:
> On Tue, 5 Mar 2019, mortonm@chromium.org wrote:
>
>> From: Micah Morton <mortonm@chromium.org>
>>
>> This patch generalizes the 'task_fix_setuid' LSM hook to enable hooking
>> setgid transitions as well as setuid transitions. The hook is renamed to
>> 'task_fix_setid'. The patch introduces calls to this hook from the
>> setgid functions in kernel/sys.c. This will allow the SafeSetID LSM to
>> govern setgid transitions in addition to setuid transitions. This patch
>> also makes sure the setgid functions in kernel/sys.c call
>> security_capable_setid rather than the ordinary security_capable
>> function, so that the security_capable hook in the SafeSetID LSM knows
>> it is being invoked from a setid function.
>>
>> Signed-off-by: Micah Morton <mortonm@chromium.org>
> Wondering if there are any further comments or reviews for this before it
> is merged?
My comments have been addressed.
^ permalink raw reply
* Re: LoadPin old-api-denied
From: Kees Cook @ 2019-03-29 19:39 UTC (permalink / raw)
To: Martin Townsend; +Cc: LSM
In-Reply-To: <CABatt_yJxncPXVy09j757Ff_caodTUM4S4nf399MOatQ1LdPtA@mail.gmail.com>
On Fri, Mar 29, 2019 at 11:01 AM Martin Townsend
<mtownsend1973@gmail.com> wrote:
>
> On Fri, Mar 29, 2019 at 5:26 PM Martin Townsend <mtownsend1973@gmail.com> wrote:
> >
> > Hi,
> >
> > I'm seeing the following message when trying to load some backported
> > kernel modules:
> > Mar 29 16:24:09 mach-cw-rnet-ppm-1840 kernel: LoadPin: kernel-module
> > old-api-denied obj=<unknown> pid=340 cmdline="modprobe compat"
> >
> > I have other kernel modules that were built out of tree and these load
> > fine, the only difference I can see is that they are loaded via
> > /etc/modules-load.d
> >
> > I've read through the loadpin docs and it states that it will only
> > allow modules that are from the main root filesystem and that
> > filesystem is read-only. I've checked and both of these are true for
> > the failing module. I've read through the source code and there's a
> > comment above the code path that loadpin is taking where the file
> > pointer is NULL.
> > /* This handles the older init_module API that has a NULL file. */
> > if (!file) {
> >
> > I'm not 100% sure what this means, but could it be that
> > modprobe/insmod are using this older init_module API? if so how can I
> > get around this, I need to manually insert these modules at an
> > appropriate time during boot?
> >
> > Any help greatly appreciated,
> >
> > Martin.
>
> After sending this I then found this post:
> https://lwn.net/Articles/519010/
>
> So I think I need to write some C code to use finit_module so I will try this.
It sounds like you have a mix of finit_module and init_module? Also,
if you're not intending to enforce loadpinning, you can also either
boot with "loadpin.enforce=0" or build with
CONFIG_SECURITY_LOADPIN_ENFORCE unset.
-Kees
--
Kees Cook
^ permalink raw reply
* [PATCH] LSM: Revive CONFIG_DEFAULT_SECURITY_* for "make oldconfig"
From: Kees Cook @ 2019-03-29 19:36 UTC (permalink / raw)
To: James Morris
Cc: Tetsuo Handa, Jakub Kicinski, Randy Dunlap, linux-security-module,
linux-kernel
Commit 70b62c25665f636c ("LoadPin: Initialize as ordered LSM") removed
CONFIG_DEFAULT_SECURITY_{SELINUX,SMACK,TOMOYO,APPARMOR,DAC} from
security/Kconfig and changed CONFIG_LSM to provide a fixed ordering as a
default value. That commit expected that existing users (upgrading from
Linux 5.0 and earlier) will edit CONFIG_LSM value in accordance with
their CONFIG_DEFAULT_SECURITY_* choice in their old kernel configs. But
since users might forget to edit CONFIG_LSM value, this patch revives
the choice (only for providing the default value for CONFIG_LSM) in order
to make sure that CONFIG_LSM reflects CONFIG_DEFAULT_SECURITY_* from their
old kernel configs.
Note that since TOMOYO can be fully stacked against the other legacy
major LSMs, when it is selected, it explicitly disables the other LSMs
to avoid them also initializing since TOMOYO does not expect this
currently.
Reported-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Fixes: 70b62c25665f636c ("LoadPin: Initialize as ordered LSM")
Co-developed-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: Kees Cook <keescook@chromium.org>
Acked-by: Casey Schaufler <casey@schaufler-ca.com>
---
security/Kconfig | 38 ++++++++++++++++++++++++++++++++++++++
1 file changed, 38 insertions(+)
diff --git a/security/Kconfig b/security/Kconfig
index 1d6463fb1450..353cfef71d4e 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -239,8 +239,46 @@ source "security/safesetid/Kconfig"
source "security/integrity/Kconfig"
+choice
+ prompt "First legacy 'major LSM' to be initialized"
+ default DEFAULT_SECURITY_SELINUX if SECURITY_SELINUX
+ default DEFAULT_SECURITY_SMACK if SECURITY_SMACK
+ default DEFAULT_SECURITY_TOMOYO if SECURITY_TOMOYO
+ default DEFAULT_SECURITY_APPARMOR if SECURITY_APPARMOR
+ default DEFAULT_SECURITY_DAC
+
+ help
+ This choice is there only for converting CONFIG_DEFAULT_SECURITY
+ in old kernel configs to CONFIG_LSM in new kernel configs. Don't
+ change this choice unless you are creating a fresh kernel config,
+ for this choice will be ignored after CONFIG_LSM has been set.
+
+ Selects the legacy "major security module" that will be
+ initialized first. Overridden by non-default CONFIG_LSM.
+
+ config DEFAULT_SECURITY_SELINUX
+ bool "SELinux" if SECURITY_SELINUX=y
+
+ config DEFAULT_SECURITY_SMACK
+ bool "Simplified Mandatory Access Control" if SECURITY_SMACK=y
+
+ config DEFAULT_SECURITY_TOMOYO
+ bool "TOMOYO" if SECURITY_TOMOYO=y
+
+ config DEFAULT_SECURITY_APPARMOR
+ bool "AppArmor" if SECURITY_APPARMOR=y
+
+ config DEFAULT_SECURITY_DAC
+ bool "Unix Discretionary Access Controls"
+
+endchoice
+
config LSM
string "Ordered list of enabled LSMs"
+ default "yama,loadpin,safesetid,integrity,smack,selinux,tomoyo,apparmor" if DEFAULT_SECURITY_SMACK
+ default "yama,loadpin,safesetid,integrity,apparmor,selinux,smack,tomoyo" if DEFAULT_SECURITY_APPARMOR
+ default "yama,loadpin,safesetid,integrity,tomoyo" if DEFAULT_SECURITY_TOMOYO
+ default "yama,loadpin,safesetid,integrity" if DEFAULT_SECURITY_DAC
default "yama,loadpin,safesetid,integrity,selinux,smack,tomoyo,apparmor"
help
A comma-separated list of LSMs, in initialization order.
--
2.17.1
--
Kees Cook
^ permalink raw reply related
* Re: [GIT PULL] tpmdd fixes for Linux v5.1
From: James Morris @ 2019-03-29 18:41 UTC (permalink / raw)
To: Jarkko Sakkinen; +Cc: linux-kernel, linux-security-module, linux-integrity
In-Reply-To: <20190329115544.GA27351@linux.intel.com>
On Fri, 29 Mar 2019, Jarkko Sakkinen wrote:
> Hi James,
>
> These are critical fixes for v5.1. Contains also couple of new selftests for
> v5.1 features (partial reads in /dev/tpm0). I hope these could still reach
> the release. Thanks.
Applied to
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next-tpm
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* [GIT PULL] security: yama fix for v5.1
From: James Morris @ 2019-03-29 18:10 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-security-module, linux-kernel
Please pull this fix for the Yama LSM by Jann Horn.
The following changes since commit 8c7ae38d1ce12a0eaeba655df8562552b3596c7f:
afs: Fix StoreData op marshalling (2019-03-28 08:54:20 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git fixes-v5.1
for you to fetch changes up to 1aa176ef5a451adc0546d5aaa3fb107975c786b7:
Yama: mark local symbols as static (2019-03-28 10:02:29 -0700)
----------------------------------------------------------------
Jann Horn (1):
Yama: mark local symbols as static
security/yama/yama_lsm.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
---
commit 1aa176ef5a451adc0546d5aaa3fb107975c786b7
Author: Jann Horn <jannh@google.com>
Date: Wed Mar 27 17:21:42 2019 -0700
Yama: mark local symbols as static
sparse complains that Yama defines functions and a variable as non-static
even though they don't exist in any header. Fix it by making them static.
Co-developed-by: Mukesh Ojha <mojha@codeaurora.org>
Signed-off-by: Mukesh Ojha <mojha@codeaurora.org>
Signed-off-by: Jann Horn <jannh@google.com>
[kees: merged similar static-ness fixes into a single patch]
Link: https://lkml.kernel.org/r/20190326230841.87834-1-jannh@google.com
Link: https://lkml.kernel.org/r/1553673018-19234-1-git-send-email-mojha@codeaurora.org
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: James Morris <james.morris@microsoft.com>
diff --git a/security/yama/yama_lsm.c b/security/yama/yama_lsm.c
index 57cc60722dd3..efac68556b45 100644
--- a/security/yama/yama_lsm.c
+++ b/security/yama/yama_lsm.c
@@ -206,7 +206,7 @@ static void yama_ptracer_del(struct task_struct *tracer,
* yama_task_free - check for task_pid to remove from exception list
* @task: task being removed
*/
-void yama_task_free(struct task_struct *task)
+static void yama_task_free(struct task_struct *task)
{
yama_ptracer_del(task, task);
}
@@ -222,7 +222,7 @@ void yama_task_free(struct task_struct *task)
* Return 0 on success, -ve on error. -ENOSYS is returned when Yama
* does not handle the given option.
*/
-int yama_task_prctl(int option, unsigned long arg2, unsigned long arg3,
+static int yama_task_prctl(int option, unsigned long arg2, unsigned long arg3,
unsigned long arg4, unsigned long arg5)
{
int rc = -ENOSYS;
@@ -401,7 +401,7 @@ static int yama_ptrace_access_check(struct task_struct *child,
*
* Returns 0 if following the ptrace is allowed, -ve on error.
*/
-int yama_ptrace_traceme(struct task_struct *parent)
+static int yama_ptrace_traceme(struct task_struct *parent)
{
int rc = 0;
@@ -452,7 +452,7 @@ static int yama_dointvec_minmax(struct ctl_table *table, int write,
static int zero;
static int max_scope = YAMA_SCOPE_NO_ATTACH;
-struct ctl_path yama_sysctl_path[] = {
+static struct ctl_path yama_sysctl_path[] = {
{ .procname = "kernel", },
{ .procname = "yama", },
{ }
^ permalink raw reply related
* Re: Linux 5.1-rc2
From: James Morris @ 2019-03-29 18:07 UTC (permalink / raw)
To: Kees Cook
Cc: Tetsuo Handa, Randy Dunlap, Linus Torvalds,
Linux List Kernel Mailing, linux-security-module, Jakub Kicinski
In-Reply-To: <CAGXu5jL0YzgQR_p9otyOX4+00a0i7Tfv9aLqauZFZs4-Kfjakg@mail.gmail.com>
On Wed, 27 Mar 2019, Kees Cook wrote:
> > There should be no problem except some TOMOYO messages are printed.
>
> Okay, so I should send my latest version of the patch to James? Or do
> you explicitly want TOMOYO removed from all the CONFIG_LSM default
> lines except when selected by CONFIG_DEFAULT_SECURITY_TOMOYO? (I worry
> the latter will lead to less testing of the stacking.)
Kees, send me your final patch as soon as it's ready.
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: [PATCH v5 1/2] LSM: SafeSetID: gate setgid transitions
From: James Morris @ 2019-03-29 18:06 UTC (permalink / raw)
To: Micah Morton; +Cc: serge, keescook, casey, sds, linux-security-module
In-Reply-To: <20190305154922.61040-1-mortonm@chromium.org>
On Tue, 5 Mar 2019, mortonm@chromium.org wrote:
> From: Micah Morton <mortonm@chromium.org>
>
> This patch generalizes the 'task_fix_setuid' LSM hook to enable hooking
> setgid transitions as well as setuid transitions. The hook is renamed to
> 'task_fix_setid'. The patch introduces calls to this hook from the
> setgid functions in kernel/sys.c. This will allow the SafeSetID LSM to
> govern setgid transitions in addition to setuid transitions. This patch
> also makes sure the setgid functions in kernel/sys.c call
> security_capable_setid rather than the ordinary security_capable
> function, so that the security_capable hook in the SafeSetID LSM knows
> it is being invoked from a setid function.
>
> Signed-off-by: Micah Morton <mortonm@chromium.org>
Wondering if there are any further comments or reviews for this before it
is merged?
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: LoadPin old-api-denied
From: Martin Townsend @ 2019-03-29 18:01 UTC (permalink / raw)
To: LSM, keescook
In-Reply-To: <CABatt_wR2t_jLYx3=-uivpDHnGpozdhBzZOBcz3KJ=Mi-PikBw@mail.gmail.com>
On Fri, Mar 29, 2019 at 5:26 PM Martin Townsend <mtownsend1973@gmail.com> wrote:
>
> Hi,
>
> I'm seeing the following message when trying to load some backported
> kernel modules:
> Mar 29 16:24:09 mach-cw-rnet-ppm-1840 kernel: LoadPin: kernel-module
> old-api-denied obj=<unknown> pid=340 cmdline="modprobe compat"
>
> I have other kernel modules that were built out of tree and these load
> fine, the only difference I can see is that they are loaded via
> /etc/modules-load.d
>
> I've read through the loadpin docs and it states that it will only
> allow modules that are from the main root filesystem and that
> filesystem is read-only. I've checked and both of these are true for
> the failing module. I've read through the source code and there's a
> comment above the code path that loadpin is taking where the file
> pointer is NULL.
> /* This handles the older init_module API that has a NULL file. */
> if (!file) {
>
> I'm not 100% sure what this means, but could it be that
> modprobe/insmod are using this older init_module API? if so how can I
> get around this, I need to manually insert these modules at an
> appropriate time during boot?
>
> Any help greatly appreciated,
>
> Martin.
After sending this I then found this post:
https://lwn.net/Articles/519010/
So I think I need to write some C code to use finit_module so I will try this.
^ permalink raw reply
* Re: [PATCH 2/2 v2] efi: print appropriate status message when loading certificates
From: jlee @ 2019-03-29 17:40 UTC (permalink / raw)
To: Mimi Zohar
Cc: Lee, Chun-Yi, Ard Biesheuvel, James Morris, Serge E . Hallyn,
David Howells, Josh Boyer, Nayna Jain, linux-efi,
linux-security-module, linux-kernel
In-Reply-To: <1553714635.4608.34.camel@linux.ibm.com>
On Wed, Mar 27, 2019 at 03:23:55PM -0400, Mimi Zohar wrote:
> On Sun, 2019-03-24 at 08:26 +0800, Lee, Chun-Yi wrote:
> > When loading certificates list from UEFI variable, the original error
> > message direct shows the efi status code from UEFI firmware. It looks
> > ugly:
> >
> > [ 2.335031] Couldn't get size: 0x800000000000000e
> > [ 2.335032] Couldn't get UEFI MokListRT
> > [ 2.339985] Couldn't get size: 0x800000000000000e
> > [ 2.339987] Couldn't get UEFI dbx list
> >
> > So, this patch shows the status string instead of status code.
> >
> > On the other hand, the "Couldn't get UEFI" message doesn't need
> > to be exposed when db/dbx/mok variable do not exist. So, this
> > patch set the message level to debug.
> >
> > v2.
> > Setting the MODSIGN messagse level to debug.
> >
> > Link: https://forums.opensuse.org/showthread.php/535324-MODSIGN-Couldn-t-get-UEFI-db-list?p=2897516#post2897516
> > Cc: James Morris <jmorris@namei.org>
> > Cc: Serge E. Hallyn" <serge@hallyn.com>
> > Cc: David Howells <dhowells@redhat.com>
> > Cc: Nayna Jain <nayna@linux.ibm.com>
> > Cc: Josh Boyer <jwboyer@fedoraproject.org>
> > Cc: Mimi Zohar <zohar@linux.ibm.com>
> > Signed-off-by: "Lee, Chun-Yi" <jlee@suse.com>
> > ---
> > security/integrity/platform_certs/load_uefi.c | 13 ++++++++-----
> > 1 file changed, 8 insertions(+), 5 deletions(-)
> >
> > diff --git a/security/integrity/platform_certs/load_uefi.c b/security/integrity/platform_certs/load_uefi.c
> > index 81b19c52832b..e65244b31f04 100644
> > --- a/security/integrity/platform_certs/load_uefi.c
> > +++ b/security/integrity/platform_certs/load_uefi.c
> > @@ -48,7 +48,9 @@ static __init void *get_cert_list(efi_char16_t *name, efi_guid_t *guid,
> >
> > status = efi.get_variable(name, guid, NULL, &lsize, &tmpdb);
> > if (status != EFI_BUFFER_TOO_SMALL) {
> > - pr_err("Couldn't get size: 0x%lx\n", status);
> > + if (status != EFI_NOT_FOUND)
> > + pr_err("Couldn't get size: %s\n",
> > + efi_status_to_str(status));
> > return NULL;
> > }
> >
> > @@ -59,7 +61,8 @@ static __init void *get_cert_list(efi_char16_t *name, efi_guid_t *guid,
> > status = efi.get_variable(name, guid, NULL, &lsize, db);
> > if (status != EFI_SUCCESS) {
> > kfree(db);
> > - pr_err("Error reading db var: 0x%lx\n", status);
> > + pr_err("Error reading db var: %s\n",
> > + efi_status_to_str(status));
> > return NULL;
> > }
> >
> > @@ -155,7 +158,7 @@ static int __init load_uefi_certs(void)
> > if (!uefi_check_ignore_db()) {
> > db = get_cert_list(L"db", &secure_var, &dbsize);
> > if (!db) {
> > - pr_err("MODSIGN: Couldn't get UEFI db list\n");
> > + pr_debug("MODSIGN: Couldn't get UEFI db list\n");
>
> Sure, this is fine.
>
> > } else {
> > rc = parse_efi_signature_list("UEFI:db",
> > db, dbsize, get_handler_for_db);
> > @@ -168,7 +171,7 @@ static int __init load_uefi_certs(void)
> >
> > mok = get_cert_list(L"MokListRT", &mok_var, &moksize);
> > if (!mok) {
> > - pr_info("Couldn't get UEFI MokListRT\n");
> > + pr_debug("Couldn't get UEFI MokListRT\n");
>
> This is fine too.
>
> > } else {
> > rc = parse_efi_signature_list("UEFI:MokListRT",
> > mok, moksize, get_handler_for_db);
> > @@ -179,7 +182,7 @@ static int __init load_uefi_certs(void)
> >
> > dbx = get_cert_list(L"dbx", &secure_var, &dbxsize);
> > if (!dbx) {
> > - pr_info("Couldn't get UEFI dbx list\n");
> > + pr_debug("Couldn't get UEFI dbx list\n");
>
> If there isn't a db or moklist, then this is fine. My concern is not
> having an indication that the dbx wasn't installed, when it should
> have been.
>
> Perhaps similar to the "Loading compiled-in X.509 certificates"
> informational message there should informational messages for db, mok,
> and dbx as well.
>
OK. I will add message when kernel found db, dbx and mok. It will
just like the informaton message for ACPI S0,S3,S4 support.
Thanks
Joey Lee
^ permalink raw reply
* LoadPin old-api-denied
From: Martin Townsend @ 2019-03-29 17:26 UTC (permalink / raw)
To: LSM, keescook
Hi,
I'm seeing the following message when trying to load some backported
kernel modules:
Mar 29 16:24:09 mach-cw-rnet-ppm-1840 kernel: LoadPin: kernel-module
old-api-denied obj=<unknown> pid=340 cmdline="modprobe compat"
I have other kernel modules that were built out of tree and these load
fine, the only difference I can see is that they are loaded via
/etc/modules-load.d
I've read through the loadpin docs and it states that it will only
allow modules that are from the main root filesystem and that
filesystem is read-only. I've checked and both of these are true for
the failing module. I've read through the source code and there's a
comment above the code path that loadpin is taking where the file
pointer is NULL.
/* This handles the older init_module API that has a NULL file. */
if (!file) {
I'm not 100% sure what this means, but could it be that
modprobe/insmod are using this older init_module API? if so how can I
get around this, I need to manually insert these modules at an
appropriate time during boot?
Any help greatly appreciated,
Martin.
^ 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