Discussion:
[PATCH V2 04/10] ACPI: Limit access to custom_method
(too old to reply)
Matthew Garrett
2012-09-20 14:50:01 UTC
Permalink
It must be impossible for even root to get code executed in kernel context
under a secure boot environment. custom_method effectively allows arbitrary
access to system memory, so it needs to have a capability check here.

Signed-off-by: Matthew Garrett <***@redhat.com>
---
drivers/acpi/custom_method.c | 3 +++
1 file changed, 3 insertions(+)

diff --git a/drivers/acpi/custom_method.c b/drivers/acpi/custom_method.c
index 5d42c24..247d58b 100644
--- a/drivers/acpi/custom_method.c
+++ b/drivers/acpi/custom_method.c
@@ -29,6 +29,9 @@ static ssize_t cm_write(struct file *file, const char __user * user_buf,
struct acpi_table_header table;
acpi_status status;

+ if (!capable(CAP_COMPROMISE_KERNEL))
+ return -EPERM;
+
if (!(*ppos)) {
/* parse the table header to get the table length */
if (count <= sizeof(struct acpi_table_header))
--
1.7.11.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Matthew Garrett
2012-09-20 14:50:02 UTC
Permalink
Secure boot adds certain policy requirements, including that root must not
be able to do anything that could cause the kernel to execute arbitrary code.
The simplest way to handle this would seem to be to add a new capability
and gate various functionality on that. We'll then strip it from the initial
capability set if required.

Signed-off-by: Matthew Garrett <***@redhat.com>
---
include/linux/capability.h | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/include/linux/capability.h b/include/linux/capability.h
index d10b7ed..4345bc8 100644
--- a/include/linux/capability.h
+++ b/include/linux/capability.h
@@ -364,7 +364,11 @@ struct cpu_vfs_cap_data {

#define CAP_BLOCK_SUSPEND 36

-#define CAP_LAST_CAP CAP_BLOCK_SUSPEND
+/* Allow things that trivially permit root to modify the running kernel */
+
+#define CAP_COMPROMISE_KERNEL 37
+
+#define CAP_LAST_CAP CAP_COMPROMISE_KERNEL

#define cap_valid(x) ((x) >= 0 && (x) <= CAP_LAST_CAP)
--
1.7.11.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Serge Hallyn
2012-09-28 03:20:01 UTC
Permalink
Post by Matthew Garrett
Secure boot adds certain policy requirements, including that root must not
be able to do anything that could cause the kernel to execute arbitrary code.
The simplest way to handle this would seem to be to add a new capability
and gate various functionality on that. We'll then strip it from the initial
capability set if required.
---
include/linux/capability.h | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/include/linux/capability.h b/include/linux/capability.h
index d10b7ed..4345bc8 100644
--- a/include/linux/capability.h
+++ b/include/linux/capability.h
@@ -364,7 +364,11 @@ struct cpu_vfs_cap_data {
#define CAP_BLOCK_SUSPEND 36
-#define CAP_LAST_CAP CAP_BLOCK_SUSPEND
+/* Allow things that trivially permit root to modify the running kernel */
+
+#define CAP_COMPROMISE_KERNEL 37
+
+#define CAP_LAST_CAP CAP_COMPROMISE_KERNEL
#define cap_valid(x) ((x) >= 0 && (x) <= CAP_LAST_CAP)
--
1.7.11.4
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
joeyli
2012-10-20 00:20:01 UTC
Permalink
Hi Matt,

Sorry for bother you!

I didn't see this Matthew's patchset merged in EFI git tree. Do you have
plan to merge it? Or those patches need wait different subsystem leaders
merge.


Thanks a lot!
Joey Lee

於 四,2012-09-20 於 10:40 -0400,Matthew Garrett 提到:
Post by Matthew Garrett
Secure boot adds certain policy requirements, including that root must not
be able to do anything that could cause the kernel to execute arbitrary code.
The simplest way to handle this would seem to be to add a new capability
and gate various functionality on that. We'll then strip it from the initial
capability set if required.
---
include/linux/capability.h | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/include/linux/capability.h b/include/linux/capability.h
index d10b7ed..4345bc8 100644
--- a/include/linux/capability.h
+++ b/include/linux/capability.h
@@ -364,7 +364,11 @@ struct cpu_vfs_cap_data {
#define CAP_BLOCK_SUSPEND 36
-#define CAP_LAST_CAP CAP_BLOCK_SUSPEND
+/* Allow things that trivially permit root to modify the running kernel */
+
+#define CAP_COMPROMISE_KERNEL 37
+
+#define CAP_LAST_CAP CAP_COMPROMISE_KERNEL
#define cap_valid(x) ((x) >= 0 && (x) <= CAP_LAST_CAP)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Matt Fleming
2012-10-20 09:30:01 UTC
Permalink
Post by joeyli
Hi Matt,
Sorry for bother you!
I didn't see this Matthew's patchset merged in EFI git tree. Do you have
plan to merge it? Or those patches need wait different subsystem leaders
merge.
I don't think it makes sense for the secure boot patch series to go
through the EFI tree as it touches a lot of other subsystems.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Matthew Garrett
2012-09-20 14:50:02 UTC
Permalink
From: Josh Boyer <***@redhat.com>

This option allows userspace to pass the RSDP address to the kernel. This
could potentially be used to circumvent the secure boot trust model.
We ignore the setting if we don't have the CAP_COMPROMISE_KERNEL capability.

Signed-off-by: Josh Boyer <***@redhat.com>
---
drivers/acpi/osl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index 9eaf708..f94341b 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -246,7 +246,7 @@ early_param("acpi_rsdp", setup_acpi_rsdp);
acpi_physical_address __init acpi_os_get_root_pointer(void)
{
#ifdef CONFIG_KEXEC
- if (acpi_rsdp)
+ if (acpi_rsdp && capable(CAP_COMPROMISE_KERNEL))
return acpi_rsdp;
#endif
--
1.7.11.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Matthew Garrett
2012-09-20 14:50:03 UTC
Permalink
IO port access would permit users to gain access to PCI configuration
registers, which in turn (on a lot of hardware) give access to MMIO register
space. This would potentially permit root to trigger arbitrary DMA, so lock
it down by default.

Signed-off-by: Matthew Garrett <***@redhat.com>
---
arch/x86/kernel/ioport.c | 4 ++--
drivers/char/mem.c | 3 +++
2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/ioport.c b/arch/x86/kernel/ioport.c
index 8c96897..a2578c4 100644
--- a/arch/x86/kernel/ioport.c
+++ b/arch/x86/kernel/ioport.c
@@ -28,7 +28,7 @@ asmlinkage long sys_ioperm(unsigned long from, unsigned long num, int turn_on)

if ((from + num <= from) || (from + num > IO_BITMAP_BITS))
return -EINVAL;
- if (turn_on && !capable(CAP_SYS_RAWIO))
+ if (turn_on && (!capable(CAP_SYS_RAWIO) || !capable(CAP_COMPROMISE_KERNEL)))
return -EPERM;

/*
@@ -102,7 +102,7 @@ long sys_iopl(unsigned int level, struct pt_regs *regs)
return -EINVAL;
/* Trying to gain more privileges? */
if (level > old) {
- if (!capable(CAP_SYS_RAWIO))
+ if (!capable(CAP_SYS_RAWIO) || !capable(CAP_COMPROMISE_KERNEL))
return -EPERM;
}
regs->flags = (regs->flags & ~X86_EFLAGS_IOPL) | (level << 12);
diff --git a/drivers/char/mem.c b/drivers/char/mem.c
index e5eedfa2..1e0a660 100644
--- a/drivers/char/mem.c
+++ b/drivers/char/mem.c
@@ -597,6 +597,9 @@ static ssize_t write_port(struct file *file, const char __user *buf,
unsigned long i = *ppos;
const char __user * tmp = buf;

+ if (!capable(CAP_COMPROMISE_KERNEL))
+ return -EPERM;
+
if (!access_ok(VERIFY_READ, buf, count))
return -EFAULT;
while (count-- > 0 && i < 65536) {
--
1.7.11.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Matthew Garrett
2012-09-20 14:50:03 UTC
Permalink
The firmware has a set of flags that indicate whether secure boot is enabled
and enforcing. Use them to indicate whether the kernel should lock itself
down.

Signed-off-by: Matthew Garrett <***@redhat.com>
---
Documentation/x86/zero-page.txt | 2 ++
arch/x86/boot/compressed/eboot.c | 32 ++++++++++++++++++++++++++++++++
arch/x86/include/asm/bootparam.h | 3 ++-
arch/x86/kernel/setup.c | 3 +++
include/linux/cred.h | 2 ++
5 files changed, 41 insertions(+), 1 deletion(-)

diff --git a/Documentation/x86/zero-page.txt b/Documentation/x86/zero-page.txt
index cf5437d..7f9ed48 100644
--- a/Documentation/x86/zero-page.txt
+++ b/Documentation/x86/zero-page.txt
@@ -27,6 +27,8 @@ Offset Proto Name Meaning
1E9/001 ALL eddbuf_entries Number of entries in eddbuf (below)
1EA/001 ALL edd_mbr_sig_buf_entries Number of entries in edd_mbr_sig_buffer
(below)
+1EB/001 ALL kbd_status Numlock is enabled
+1EC/001 ALL secure_boot Kernel should enable secure boot lockdowns
290/040 ALL edd_mbr_sig_buffer EDD MBR signatures
2D0/A00 ALL e820_map E820 memory map table
(array of struct e820entry)
diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
index b3e0227..3789356 100644
--- a/arch/x86/boot/compressed/eboot.c
+++ b/arch/x86/boot/compressed/eboot.c
@@ -724,6 +724,36 @@ fail:
return status;
}

+static int get_secure_boot(efi_system_table_t *_table)
+{
+ u8 sb, setup;
+ unsigned long datasize = sizeof(sb);
+ efi_guid_t var_guid = EFI_GLOBAL_VARIABLE_GUID;
+ efi_status_t status;
+
+ status = efi_call_phys5(sys_table->runtime->get_variable,
+ L"SecureBoot", &var_guid, NULL, &datasize, &sb);
+
+ if (status != EFI_SUCCESS)
+ return 0;
+
+ if (sb == 0)
+ return 0;
+
+
+ status = efi_call_phys5(sys_table->runtime->get_variable,
+ L"SetupMode", &var_guid, NULL, &datasize,
+ &setup);
+
+ if (status != EFI_SUCCESS)
+ return 0;
+
+ if (setup == 1)
+ return 0;
+
+ return 1;
+}
+
/*
* Because the x86 boot code expects to be passed a boot_params we
* need to create one ourselves (usually the bootloader would create
@@ -1018,6 +1048,8 @@ struct boot_params *efi_main(void *handle, efi_system_table_t *_table,
if (sys_table->hdr.signature != EFI_SYSTEM_TABLE_SIGNATURE)
goto fail;

+ boot_params->secure_boot = get_secure_boot(sys_table);
+
setup_graphics(boot_params);

status = efi_call_phys3(sys_table->boottime->allocate_pool,
diff --git a/arch/x86/include/asm/bootparam.h b/arch/x86/include/asm/bootparam.h
index 2ad874c..c7338e0 100644
--- a/arch/x86/include/asm/bootparam.h
+++ b/arch/x86/include/asm/bootparam.h
@@ -114,7 +114,8 @@ struct boot_params {
__u8 eddbuf_entries; /* 0x1e9 */
__u8 edd_mbr_sig_buf_entries; /* 0x1ea */
__u8 kbd_status; /* 0x1eb */
- __u8 _pad6[5]; /* 0x1ec */
+ __u8 secure_boot; /* 0x1ec */
+ __u8 _pad6[4]; /* 0x1ed */
struct setup_header hdr; /* setup header */ /* 0x1f1 */
__u8 _pad7[0x290-0x1f1-sizeof(struct setup_header)];
__u32 edd_mbr_sig_buffer[EDD_MBR_SIG_MAX]; /* 0x290 */
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index f4b9b80..239bf2a 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -947,6 +947,9 @@ void __init setup_arch(char **cmdline_p)

io_delay_init();

+ if (boot_params.secure_boot)
+ secureboot_enable();
+
/*
* Parse the ACPI tables for possible boot-time SMP configuration.
*/
diff --git a/include/linux/cred.h b/include/linux/cred.h
index ebbed2c..a24faf1 100644
--- a/include/linux/cred.h
+++ b/include/linux/cred.h
@@ -170,6 +170,8 @@ extern int set_security_override_from_ctx(struct cred *, const char *);
extern int set_create_files_as(struct cred *, struct inode *);
extern void __init cred_init(void);

+extern void secureboot_enable(void);
+
/*
* check for validity of credentials
*/
--
1.7.11.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Serge Hallyn
2012-09-28 03:30:01 UTC
Permalink
Post by Matthew Garrett
The firmware has a set of flags that indicate whether secure boot is enabled
and enforcing. Use them to indicate whether the kernel should lock itself
down.
(purely for the non-firmware bits) seems good, thanks.
Post by Matthew Garrett
---
Documentation/x86/zero-page.txt | 2 ++
arch/x86/boot/compressed/eboot.c | 32 ++++++++++++++++++++++++++++++++
arch/x86/include/asm/bootparam.h | 3 ++-
arch/x86/kernel/setup.c | 3 +++
include/linux/cred.h | 2 ++
5 files changed, 41 insertions(+), 1 deletion(-)
diff --git a/Documentation/x86/zero-page.txt b/Documentation/x86/zero-page.txt
index cf5437d..7f9ed48 100644
--- a/Documentation/x86/zero-page.txt
+++ b/Documentation/x86/zero-page.txt
@@ -27,6 +27,8 @@ Offset Proto Name Meaning
1E9/001 ALL eddbuf_entries Number of entries in eddbuf (below)
1EA/001 ALL edd_mbr_sig_buf_entries Number of entries in edd_mbr_sig_buffer
(below)
+1EB/001 ALL kbd_status Numlock is enabled
+1EC/001 ALL secure_boot Kernel should enable secure boot lockdowns
290/040 ALL edd_mbr_sig_buffer EDD MBR signatures
2D0/A00 ALL e820_map E820 memory map table
(array of struct e820entry)
diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
index b3e0227..3789356 100644
--- a/arch/x86/boot/compressed/eboot.c
+++ b/arch/x86/boot/compressed/eboot.c
return status;
}
+static int get_secure_boot(efi_system_table_t *_table)
+{
+ u8 sb, setup;
+ unsigned long datasize = sizeof(sb);
+ efi_guid_t var_guid = EFI_GLOBAL_VARIABLE_GUID;
+ efi_status_t status;
+
+ status = efi_call_phys5(sys_table->runtime->get_variable,
+ L"SecureBoot", &var_guid, NULL, &datasize, &sb);
+
+ if (status != EFI_SUCCESS)
+ return 0;
+
+ if (sb == 0)
+ return 0;
+
+
+ status = efi_call_phys5(sys_table->runtime->get_variable,
+ L"SetupMode", &var_guid, NULL, &datasize,
+ &setup);
+
+ if (status != EFI_SUCCESS)
+ return 0;
+
+ if (setup == 1)
+ return 0;
+
+ return 1;
+}
+
/*
* Because the x86 boot code expects to be passed a boot_params we
* need to create one ourselves (usually the bootloader would create
@@ -1018,6 +1048,8 @@ struct boot_params *efi_main(void *handle, efi_system_table_t *_table,
if (sys_table->hdr.signature != EFI_SYSTEM_TABLE_SIGNATURE)
goto fail;
+ boot_params->secure_boot = get_secure_boot(sys_table);
+
setup_graphics(boot_params);
status = efi_call_phys3(sys_table->boottime->allocate_pool,
diff --git a/arch/x86/include/asm/bootparam.h b/arch/x86/include/asm/bootparam.h
index 2ad874c..c7338e0 100644
--- a/arch/x86/include/asm/bootparam.h
+++ b/arch/x86/include/asm/bootparam.h
@@ -114,7 +114,8 @@ struct boot_params {
__u8 eddbuf_entries; /* 0x1e9 */
__u8 edd_mbr_sig_buf_entries; /* 0x1ea */
__u8 kbd_status; /* 0x1eb */
- __u8 _pad6[5]; /* 0x1ec */
+ __u8 secure_boot; /* 0x1ec */
+ __u8 _pad6[4]; /* 0x1ed */
struct setup_header hdr; /* setup header */ /* 0x1f1 */
__u8 _pad7[0x290-0x1f1-sizeof(struct setup_header)];
__u32 edd_mbr_sig_buffer[EDD_MBR_SIG_MAX]; /* 0x290 */
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index f4b9b80..239bf2a 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -947,6 +947,9 @@ void __init setup_arch(char **cmdline_p)
io_delay_init();
+ if (boot_params.secure_boot)
+ secureboot_enable();
+
/*
* Parse the ACPI tables for possible boot-time SMP configuration.
*/
diff --git a/include/linux/cred.h b/include/linux/cred.h
index ebbed2c..a24faf1 100644
--- a/include/linux/cred.h
+++ b/include/linux/cred.h
@@ -170,6 +170,8 @@ extern int set_security_override_from_ctx(struct cred *, const char *);
extern int set_create_files_as(struct cred *, struct inode *);
extern void __init cred_init(void);
+extern void secureboot_enable(void);
+
/*
* check for validity of credentials
*/
--
1.7.11.4
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Matt Fleming
2012-10-22 13:30:02 UTC
Permalink
Post by Matthew Garrett
The firmware has a set of flags that indicate whether secure boot is enabled
and enforcing. Use them to indicate whether the kernel should lock itself
down.
---
Documentation/x86/zero-page.txt | 2 ++
arch/x86/boot/compressed/eboot.c | 32 ++++++++++++++++++++++++++++++++
arch/x86/include/asm/bootparam.h | 3 ++-
arch/x86/kernel/setup.c | 3 +++
include/linux/cred.h | 2 ++
5 files changed, 41 insertions(+), 1 deletion(-)
Probably wants an update to Documentation/x86/boot.txt too. But
otherwise,

Acked-by: Matt Fleming <***@intel.com>


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Matthew Garrett
2012-09-20 14:50:04 UTC
Permalink
Any hardware that can potentially generate DMA has to be locked down from
userspace in order to avoid it being possible for an attacker to cause
arbitrary kernel behaviour. Default to paranoid - in future we can
potentially relax this for sufficiently IOMMU-isolated devices.

Signed-off-by: Matthew Garrett <***@redhat.com>
---
drivers/pci/pci-sysfs.c | 9 +++++++++
drivers/pci/proc.c | 8 +++++++-
drivers/pci/syscall.c | 2 +-
3 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
index 02d107b..c31b4be 100644
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -580,6 +580,9 @@ pci_write_config(struct file* filp, struct kobject *kobj,
loff_t init_off = off;
u8 *data = (u8*) buf;

+ if (!capable(CAP_COMPROMISE_KERNEL))
+ return -EPERM;
+
if (off > dev->cfg_size)
return 0;
if (off + count > dev->cfg_size) {
@@ -886,6 +889,9 @@ pci_mmap_resource(struct kobject *kobj, struct bin_attribute *attr,
resource_size_t start, end;
int i;

+ if (!capable(CAP_COMPROMISE_KERNEL))
+ return -EPERM;
+
for (i = 0; i < PCI_ROM_RESOURCE; i++)
if (res == &pdev->resource[i])
break;
@@ -993,6 +999,9 @@ pci_write_resource_io(struct file *filp, struct kobject *kobj,
struct bin_attribute *attr, char *buf,
loff_t off, size_t count)
{
+ if (!capable(CAP_COMPROMISE_KERNEL))
+ return -EPERM;
+
return pci_resource_io(filp, kobj, attr, buf, off, count, true);
}

diff --git a/drivers/pci/proc.c b/drivers/pci/proc.c
index 27911b5..ac8c9a5 100644
--- a/drivers/pci/proc.c
+++ b/drivers/pci/proc.c
@@ -135,6 +135,9 @@ proc_bus_pci_write(struct file *file, const char __user *buf, size_t nbytes, lof
int size = dp->size;
int cnt;

+ if (!capable(CAP_COMPROMISE_KERNEL))
+ return -EPERM;
+
if (pos >= size)
return 0;
if (nbytes >= size)
@@ -211,6 +214,9 @@ static long proc_bus_pci_ioctl(struct file *file, unsigned int cmd,
#endif /* HAVE_PCI_MMAP */
int ret = 0;

+ if (!capable(CAP_COMPROMISE_KERNEL))
+ return -EPERM;
+
switch (cmd) {
case PCIIOC_CONTROLLER:
ret = pci_domain_nr(dev->bus);
@@ -251,7 +257,7 @@ static int proc_bus_pci_mmap(struct file *file, struct vm_area_struct *vma)
struct pci_filp_private *fpriv = file->private_data;
int i, ret;

- if (!capable(CAP_SYS_RAWIO))
+ if (!capable(CAP_SYS_RAWIO) || !capable(CAP_COMPROMISE_KERNEL))
return -EPERM;

/* Make sure the caller is mapping a real resource for this device */
diff --git a/drivers/pci/syscall.c b/drivers/pci/syscall.c
index e1c1ec5..97e785f 100644
--- a/drivers/pci/syscall.c
+++ b/drivers/pci/syscall.c
@@ -92,7 +92,7 @@ SYSCALL_DEFINE5(pciconfig_write, unsigned long, bus, unsigned long, dfn,
u32 dword;
int err = 0;

- if (!capable(CAP_SYS_ADMIN))
+ if (!capable(CAP_SYS_ADMIN) || !capable(CAP_COMPROMISE_KERNEL))
return -EPERM;

dev = pci_get_bus_and_slot(bus, dfn);
--
1.7.11.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Matthew Garrett
2012-09-20 14:50:04 UTC
Permalink
We have no way of validating what all of the Asus WMI methods do on a
given machine, and there's a risk that some will allow hardware state to
be manipulated in such a way that arbitrary code can be executed in the
kernel. Add a capability check to prevent that.

Signed-off-by: Matthew Garrett <***@redhat.com>
---
drivers/platform/x86/asus-wmi.c | 9 +++++++++
1 file changed, 9 insertions(+)

diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
index c0e9ff4..3c10167 100644
--- a/drivers/platform/x86/asus-wmi.c
+++ b/drivers/platform/x86/asus-wmi.c
@@ -1521,6 +1521,9 @@ static int show_dsts(struct seq_file *m, void *data)
int err;
u32 retval = -1;

+ if (!capable(CAP_COMPROMISE_KERNEL))
+ return -EPERM;
+
err = asus_wmi_get_devstate(asus, asus->debug.dev_id, &retval);

if (err < 0)
@@ -1537,6 +1540,9 @@ static int show_devs(struct seq_file *m, void *data)
int err;
u32 retval = -1;

+ if (!capable(CAP_COMPROMISE_KERNEL))
+ return -EPERM;
+
err = asus_wmi_set_devstate(asus->debug.dev_id, asus->debug.ctrl_param,
&retval);

@@ -1561,6 +1567,9 @@ static int show_call(struct seq_file *m, void *data)
union acpi_object *obj;
acpi_status status;

+ if (!capable(CAP_COMPROMISE_KERNEL))
+ return -EPERM;
+
status = wmi_evaluate_method(ASUS_WMI_MGMT_GUID,
1, asus->debug.method_id,
&input, &output);
--
1.7.11.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Matthew Garrett
2012-09-20 14:50:04 UTC
Permalink
From: Josh Boyer <***@redhat.com>

This forcibly drops CAP_COMPROMISE_KERNEL from both cap_permitted and cap_bset
in the init_cred struct, which everything else inherits from. This works on
any machine and can be used to develop even if the box doesn't have UEFI.

Signed-off-by: Josh Boyer <***@redhat.com>
---
kernel/cred.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)

diff --git a/kernel/cred.c b/kernel/cred.c
index de728ac..7e6e83f 100644
--- a/kernel/cred.c
+++ b/kernel/cred.c
@@ -623,6 +623,23 @@ void __init cred_init(void)
0, SLAB_HWCACHE_ALIGN|SLAB_PANIC, NULL);
}

+void __init secureboot_enable()
+{
+ pr_info("Secure boot enabled\n");
+ cap_lower((&init_cred)->cap_bset, CAP_COMPROMISE_KERNEL);
+ cap_lower((&init_cred)->cap_permitted, CAP_COMPROMISE_KERNEL);
+}
+
+/* Dummy Secure Boot enable option to fake out UEFI SB=1 */
+static int __init secureboot_enable_opt(char *str)
+{
+ int sb_enable = !!simple_strtol(str, NULL, 0);
+ if (sb_enable)
+ secureboot_enable();
+ return 1;
+}
+__setup("secureboot_enable=", secureboot_enable_opt);
+
/**
* prepare_kernel_cred - Prepare a set of credentials for a kernel service
* @daemon: A userspace daemon to be used as a reference
--
1.7.11.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Greg KH
2012-09-20 16:40:02 UTC
Permalink
Post by Matthew Garrett
This forcibly drops CAP_COMPROMISE_KERNEL from both cap_permitted and cap_bset
in the init_cred struct, which everything else inherits from. This works on
any machine and can be used to develop even if the box doesn't have UEFI.
---
kernel/cred.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/kernel/cred.c b/kernel/cred.c
index de728ac..7e6e83f 100644
--- a/kernel/cred.c
+++ b/kernel/cred.c
@@ -623,6 +623,23 @@ void __init cred_init(void)
0, SLAB_HWCACHE_ALIGN|SLAB_PANIC, NULL);
}
+void __init secureboot_enable()
+{
+ pr_info("Secure boot enabled\n");
+ cap_lower((&init_cred)->cap_bset, CAP_COMPROMISE_KERNEL);
+ cap_lower((&init_cred)->cap_permitted, CAP_COMPROMISE_KERNEL);
+}
+
+/* Dummy Secure Boot enable option to fake out UEFI SB=1 */
+static int __init secureboot_enable_opt(char *str)
+{
+ int sb_enable = !!simple_strtol(str, NULL, 0);
+ if (sb_enable)
+ secureboot_enable();
+ return 1;
+}
+__setup("secureboot_enable=", secureboot_enable_opt);
Document this please in the bootparams file.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Josh Boyer
2012-09-20 17:50:02 UTC
Permalink
Post by Greg KH
Post by Matthew Garrett
This forcibly drops CAP_COMPROMISE_KERNEL from both cap_permitted and cap_bset
in the init_cred struct, which everything else inherits from. This works on
any machine and can be used to develop even if the box doesn't have UEFI.
---
kernel/cred.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/kernel/cred.c b/kernel/cred.c
index de728ac..7e6e83f 100644
--- a/kernel/cred.c
+++ b/kernel/cred.c
@@ -623,6 +623,23 @@ void __init cred_init(void)
0, SLAB_HWCACHE_ALIGN|SLAB_PANIC, NULL);
}
+void __init secureboot_enable()
+{
+ pr_info("Secure boot enabled\n");
+ cap_lower((&init_cred)->cap_bset, CAP_COMPROMISE_KERNEL);
+ cap_lower((&init_cred)->cap_permitted, CAP_COMPROMISE_KERNEL);
+}
+
+/* Dummy Secure Boot enable option to fake out UEFI SB=1 */
+static int __init secureboot_enable_opt(char *str)
+{
+ int sb_enable = !!simple_strtol(str, NULL, 0);
+ if (sb_enable)
+ secureboot_enable();
+ return 1;
+}
+__setup("secureboot_enable=", secureboot_enable_opt);
Document this please in the bootparams file.
Oops, yes. Will do. Thanks for pointing it out.

josh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Josh Boyer
2012-09-25 13:10:02 UTC
Permalink
This forcibly drops CAP_COMPROMISE_KERNEL from both cap_permitted and cap_bset
in the init_cred struct, which everything else inherits from. This works on
any machine and can be used to develop even if the box doesn't have UEFI.

Signed-off-by: Josh Boyer <***@redhat.com>
---
Documentation/kernel-parameters.txt | 7 +++++++
kernel/cred.c | 17 +++++++++++++++++
2 files changed, 24 insertions(+)

diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 9b2b8d3..93978d5 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -2562,6 +2562,13 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
Note: increases power consumption, thus should only be
enabled if running jitter sensitive (HPC/RT) workloads.

+ secureboot_enable=
+ [KNL] Enables an emulated UEFI Secure Boot mode. This
+ locks down various aspects of the kernel guarded by the
+ CAP_COMPROMISE_KERNEL capability. This includes things
+ like /dev/mem, IO port access, and other areas. It can
+ be used on non-UEFI machines for testing purposes.
+
security= [SECURITY] Choose a security module to enable at boot.
If this boot parameter is not specified, only the first
security module asking for security registration will be
diff --git a/kernel/cred.c b/kernel/cred.c
index de728ac..7e6e83f 100644
--- a/kernel/cred.c
+++ b/kernel/cred.c
@@ -623,6 +623,23 @@ void __init cred_init(void)
0, SLAB_HWCACHE_ALIGN|SLAB_PANIC, NULL);
}

+void __init secureboot_enable()
+{
+ pr_info("Secure boot enabled\n");
+ cap_lower((&init_cred)->cap_bset, CAP_COMPROMISE_KERNEL);
+ cap_lower((&init_cred)->cap_permitted, CAP_COMPROMISE_KERNEL);
+}
+
+/* Dummy Secure Boot enable option to fake out UEFI SB=1 */
+static int __init secureboot_enable_opt(char *str)
+{
+ int sb_enable = !!simple_strtol(str, NULL, 0);
+ if (sb_enable)
+ secureboot_enable();
+ return 1;
+}
+__setup("secureboot_enable=", secureboot_enable_opt);
+
/**
* prepare_kernel_cred - Prepare a set of credentials for a kernel service
* @daemon: A userspace daemon to be used as a reference
--
1.7.11.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
joeyli
2012-10-29 09:10:02 UTC
Permalink
Hi Josh,

於 二,2012-09-25 於 09:08 -0400,Josh Boyer 提到:
Post by Matthew Garrett
This forcibly drops CAP_COMPROMISE_KERNEL from both cap_permitted and cap_bset
in the init_cred struct, which everything else inherits from. This works on
any machine and can be used to develop even if the box doesn't have UEFI.
---
Documentation/kernel-parameters.txt | 7 +++++++
kernel/cred.c | 17 +++++++++++++++++
2 files changed, 24 insertions(+)
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 9b2b8d3..93978d5 100644
...
Post by Matthew Garrett
diff --git a/kernel/cred.c b/kernel/cred.c
index de728ac..7e6e83f 100644
--- a/kernel/cred.c
+++ b/kernel/cred.c
@@ -623,6 +623,23 @@ void __init cred_init(void)
0, SLAB_HWCACHE_ALIGN|SLAB_PANIC, NULL);
}
+void __init secureboot_enable()
+{
...
Post by Matthew Garrett
+
+/* Dummy Secure Boot enable option to fake out UEFI SB=1 */
+static int __init secureboot_enable_opt(char *str)
+{
+ int sb_enable = !!simple_strtol(str, NULL, 0);
+ if (sb_enable)
+ secureboot_enable();
+ return 1;
+}
+__setup("secureboot_enable=", secureboot_enable_opt);
+
Tahashi has a good idea for use strtobool to allow
'secureboot_enable=yes' works. Please consider the following change.


Thanks a lot!
Joey Lee
Post by Matthew Garrett
From f6841a476f3d332fe7b04cb716e0b518cccd5055 Mon Sep 17 00:00:00 2001
From: Lee, Chun-Yi <***@suse.com>
Date: Mon, 29 Oct 2012 16:36:57 +0800
Subject: [PATCH] efi: more user-friendly secureboot_enable parameter

From: Takashi Iwai <***@suse.de>

Use strtobool can allow 'secureboot_enable=yes', it's more user-friendly.

Signed-off-by: Lee, Chun-Yi <***@suse.com>
---
kernel/cred.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/kernel/cred.c b/kernel/cred.c
index 3f5be65..70897a2 100644
--- a/kernel/cred.c
+++ b/kernel/cred.c
@@ -633,9 +633,10 @@ void __init secureboot_enable()
/* Dummy Secure Boot enable option to fake out UEFI SB=1 */
static int __init secureboot_enable_opt(char *str)
{
- int sb_enable = !!simple_strtol(str, NULL, 0);
- if (sb_enable)
+ bool sb_enable;
+ if (!strtobool(str, &sb_enable) && sb_enable)
secureboot_enable();
+
return 1;
}
__setup("secureboot_enable=", secureboot_enable_opt);
--
1.6.0.2




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Josh Boyer
2012-10-30 17:50:02 UTC
Permalink
Post by joeyli
Hi Josh,
Tahashi has a good idea for use strtobool to allow
'secureboot_enable=yes' works. Please consider the following change.
Thanks a lot!
Joey Lee
Post by Matthew Garrett
From f6841a476f3d332fe7b04cb716e0b518cccd5055 Mon Sep 17 00:00:00 2001
Date: Mon, 29 Oct 2012 16:36:57 +0800
Subject: [PATCH] efi: more user-friendly secureboot_enable parameter
Use strtobool can allow 'secureboot_enable=yes', it's more user-friendly.
---
kernel/cred.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/kernel/cred.c b/kernel/cred.c
index 3f5be65..70897a2 100644
--- a/kernel/cred.c
+++ b/kernel/cred.c
@@ -633,9 +633,10 @@ void __init secureboot_enable()
/* Dummy Secure Boot enable option to fake out UEFI SB=1 */
static int __init secureboot_enable_opt(char *str)
{
- int sb_enable = !!simple_strtol(str, NULL, 0);
- if (sb_enable)
+ bool sb_enable;
+ if (!strtobool(str, &sb_enable) && sb_enable)
secureboot_enable();
+
return 1;
}
__setup("secureboot_enable=", secureboot_enable_opt);
This seems like a good change to me. If you don't mind, I'll rework the
existing patch to do this since it hasn't been accepted upstream yet and
give Takashi-san and you appropriate credit in the commit log.

josh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
joeyli
2012-10-30 19:30:03 UTC
Permalink
於 二,2012-10-30 於 13:48 -0400,Josh Boyer 提到:
Post by Josh Boyer
Post by joeyli
Hi Josh,
Tahashi has a good idea for use strtobool to allow
'secureboot_enable=yes' works. Please consider the following change.
Thanks a lot!
Joey Lee
Post by Matthew Garrett
From f6841a476f3d332fe7b04cb716e0b518cccd5055 Mon Sep 17 00:00:00 2001
Date: Mon, 29 Oct 2012 16:36:57 +0800
Subject: [PATCH] efi: more user-friendly secureboot_enable parameter
Use strtobool can allow 'secureboot_enable=yes', it's more user-friendly.
---
kernel/cred.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/kernel/cred.c b/kernel/cred.c
index 3f5be65..70897a2 100644
--- a/kernel/cred.c
+++ b/kernel/cred.c
@@ -633,9 +633,10 @@ void __init secureboot_enable()
/* Dummy Secure Boot enable option to fake out UEFI SB=1 */
static int __init secureboot_enable_opt(char *str)
{
- int sb_enable = !!simple_strtol(str, NULL, 0);
- if (sb_enable)
+ bool sb_enable;
+ if (!strtobool(str, &sb_enable) && sb_enable)
secureboot_enable();
+
return 1;
}
__setup("secureboot_enable=", secureboot_enable_opt);
This seems like a good change to me. If you don't mind, I'll rework the
existing patch to do this since it hasn't been accepted upstream yet and
give Takashi-san and you appropriate credit in the commit log.
josh
Thanks for your review and feel free add to your reworked patch.

Joey Lee


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
joeyli
2012-09-21 08:30:01 UTC
Permalink
於 四,2012-09-20 於 10:41 -0400,Matthew Garrett 提到:
Post by Matthew Garrett
This forcibly drops CAP_COMPROMISE_KERNEL from both cap_permitted and cap_bset
in the init_cred struct, which everything else inherits from. This works on
any machine and can be used to develop even if the box doesn't have UEFI.
Patch works to me for test lock the IO port access.

Tested-by: Lee, Chun-Yi <***@suse.com>

Joey Lee
Post by Matthew Garrett
---
kernel/cred.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/kernel/cred.c b/kernel/cred.c
index de728ac..7e6e83f 100644
--- a/kernel/cred.c
+++ b/kernel/cred.c
@@ -623,6 +623,23 @@ void __init cred_init(void)
0, SLAB_HWCACHE_ALIGN|SLAB_PANIC, NULL);
}
+void __init secureboot_enable()
+{
+ pr_info("Secure boot enabled\n");
+ cap_lower((&init_cred)->cap_bset, CAP_COMPROMISE_KERNEL);
+ cap_lower((&init_cred)->cap_permitted, CAP_COMPROMISE_KERNEL);
+}
+
+/* Dummy Secure Boot enable option to fake out UEFI SB=1 */
+static int __init secureboot_enable_opt(char *str)
+{
+ int sb_enable = !!simple_strtol(str, NULL, 0);
+ if (sb_enable)
+ secureboot_enable();
+ return 1;
+}
+__setup("secureboot_enable=", secureboot_enable_opt);
+
/**
* prepare_kernel_cred - Prepare a set of credentials for a kernel service
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Serge Hallyn
2012-09-28 03:30:01 UTC
Permalink
Post by Matthew Garrett
This forcibly drops CAP_COMPROMISE_KERNEL from both cap_permitted and cap_bset
in the init_cred struct, which everything else inherits from. This works on
any machine and can be used to develop even if the box doesn't have UEFI.
---
kernel/cred.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/kernel/cred.c b/kernel/cred.c
index de728ac..7e6e83f 100644
--- a/kernel/cred.c
+++ b/kernel/cred.c
@@ -623,6 +623,23 @@ void __init cred_init(void)
0, SLAB_HWCACHE_ALIGN|SLAB_PANIC, NULL);
}
+void __init secureboot_enable()
+{
+ pr_info("Secure boot enabled\n");
+ cap_lower((&init_cred)->cap_bset, CAP_COMPROMISE_KERNEL);
+ cap_lower((&init_cred)->cap_permitted, CAP_COMPROMISE_KERNEL);
+}
+
+/* Dummy Secure Boot enable option to fake out UEFI SB=1 */
+static int __init secureboot_enable_opt(char *str)
+{
+ int sb_enable = !!simple_strtol(str, NULL, 0);
+ if (sb_enable)
+ secureboot_enable();
+ return 1;
+}
+__setup("secureboot_enable=", secureboot_enable_opt);
+
/**
* prepare_kernel_cred - Prepare a set of credentials for a kernel service
--
1.7.11.4
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Matthew Garrett
2012-09-20 14:50:04 UTC
Permalink
Allowing users to write to address space makes it possible for the kernel
to be subverted. Restrict this when we need to protect the kernel.

Signed-off-by: Matthew Garrett <***@redhat.com>
---
drivers/char/mem.c | 6 ++++++
1 file changed, 6 insertions(+)

diff --git a/drivers/char/mem.c b/drivers/char/mem.c
index 1e0a660..33eb947 100644
--- a/drivers/char/mem.c
+++ b/drivers/char/mem.c
@@ -158,6 +158,9 @@ static ssize_t write_mem(struct file *file, const char __user *buf,
unsigned long copied;
void *ptr;

+ if (!capable(CAP_COMPROMISE_KERNEL))
+ return -EPERM;
+
if (!valid_phys_addr_range(p, count))
return -EFAULT;

@@ -530,6 +533,9 @@ static ssize_t write_kmem(struct file *file, const char __user *buf,
char * kbuf; /* k-addr because vwrite() takes vmlist_lock rwlock */
int err = 0;

+ if (!capable(CAP_COMPROMISE_KERNEL))
+ return -EPERM;
+
if (p < (unsigned long) high_memory) {
unsigned long to_write = min_t(unsigned long, count,
(unsigned long)high_memory - p);
--
1.7.11.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Matthew Garrett
2012-09-20 15:20:01 UTC
Permalink
From: Josh Boyer <***@redhat.com>

Add the name of the new Secure Boot capability. This allows SELinux
policies to properly map CAP_COMPROMISE_KERNEL to the appropriate
capability class.

Signed-off-by: Josh Boyer <***@redhat.com>
---
security/selinux/include/classmap.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/security/selinux/include/classmap.h b/security/selinux/include/classmap.h
index df2de54..70e2834 100644
--- a/security/selinux/include/classmap.h
+++ b/security/selinux/include/classmap.h
@@ -146,8 +146,8 @@ struct security_class_mapping secclass_map[] = {
{ "memprotect", { "mmap_zero", NULL } },
{ "peer", { "recv", NULL } },
{ "capability2",
- { "mac_override", "mac_admin", "syslog", "wake_alarm", "block_suspend",
- NULL } },
+ { "mac_override", "mac_admin", "syslog", "wake_alarm",
+ "block_suspend", "compromise_kernel", NULL } },
{ "kernel_service", { "use_as_override", "create_files_as", NULL } },
{ "tun_socket",
{ COMMON_SOCK_PERMS, NULL } },
--
1.7.11.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Eric W. Biederman
2012-09-21 23:00:01 UTC
Permalink
This is pretty much identical to the first patchset, but with the capability
renamed (CAP_COMPROMISE_KERNEL) and the kexec patch dropped. If anyone wants
to deploy these then they should disable kexec until support for signed
kexec payloads has been merged.
A couple of thoughts.

1) I don't see anything disabling kdb or kgdb. If ever there
was a way to poke into the kernel and change things...

2) You almost certainly want to disable module removal. It is all to
easy to have races where that are not properly handled in the module
removal path. I know I saw a bundle of those in debugfs the other
day.

3) And half seriously you probably want to disable mounting of
filesystems. I believe I have heard it said the kernel has not been
vetted against a hostile root user mounting deliberately corrupted
filesystem images.

As it is designed I don't believe your patchset can successfully achieve
the goal of keeping a determined root user from injecting code into the
kernel without disabling so many kernel features the kernel is
uninteresting for most people to run.

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Matthew Garrett
2012-09-22 15:30:02 UTC
Permalink
Post by Eric W. Biederman
1) I don't see anything disabling kdb or kgdb. If ever there
was a way to poke into the kernel and change things...
Is there any way to access them without having physical console access
(either the system console or a serial console)? Physically-present
attacks are kind of out of scope here.
Post by Eric W. Biederman
2) You almost certainly want to disable module removal. It is all to
easy to have races where that are not properly handled in the module
removal path. I know I saw a bundle of those in debugfs the other
day.
I'm pretty reluctant to work around bugs like this. Disabling features
certainly reduces the attack surface, but the aim is to only disable
features that *by design* permit the modification of the kernel. Where
it's possible to do so by exploiting bugs, we should be fixing the bugs.
Post by Eric W. Biederman
3) And half seriously you probably want to disable mounting of
filesystems. I believe I have heard it said the kernel has not been
vetted against a hostile root user mounting deliberately corrupted
filesystem images.
See (2). Not that you need to be root to trigger filesystem mounts, so
this is also a user->kernel exploit. Those should be fixed.
--
Matthew Garrett | ***@srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Jiri Kosina
2012-10-29 07:50:01 UTC
Permalink
This is pretty much identical to the first patchset, but with the capability
renamed (CAP_COMPROMISE_KERNEL) and the kexec patch dropped. If anyone wants
to deploy these then they should disable kexec until support for signed
kexec payloads has been merged.
Apparently your patchset currently doesn't handle device firmware loading,
nor do you seem to mention in in the comments.

I believe signed firmware loading should be put on plate as well, right?

Thanks,
--
Jiri Kosina
SUSE Labs

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Matthew Garrett
2012-10-29 17:50:01 UTC
Permalink
Post by Jiri Kosina
This is pretty much identical to the first patchset, but with the capability
renamed (CAP_COMPROMISE_KERNEL) and the kexec patch dropped. If anyone wants
to deploy these then they should disable kexec until support for signed
kexec payloads has been merged.
Apparently your patchset currently doesn't handle device firmware loading,
nor do you seem to mention in in the comments.
Correct.
Post by Jiri Kosina
I believe signed firmware loading should be put on plate as well, right?
I think that's definitely something that should be covered. I hadn't
worried about it immediately as any attack would be limited to machines
with a specific piece of hardware, and the attacker would need to expend
a significant amount of reverse engineering work on the firmware - and
we'd probably benefit from them doing that in the long run...

Having said that, yes, we should worry about this. Firmware distribution
licenses often forbid any distribution of modified versions, so
signatures would probably need to be detached. udev could easily glue
together a signature and firmware when loading, but if we're moving
towards an in-kernel firmware loader for the common case then it'll need
to be implemented there as well.
--
Matthew Garrett | ***@srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Jiri Kosina
2012-10-31 15:00:03 UTC
Permalink
Post by Matthew Garrett
Post by Jiri Kosina
This is pretty much identical to the first patchset, but with the capability
renamed (CAP_COMPROMISE_KERNEL) and the kexec patch dropped. If anyone wants
to deploy these then they should disable kexec until support for signed
kexec payloads has been merged.
Apparently your patchset currently doesn't handle device firmware loading,
nor do you seem to mention in in the comments.
Correct.
Post by Jiri Kosina
I believe signed firmware loading should be put on plate as well, right?
I think that's definitely something that should be covered. I hadn't
worried about it immediately as any attack would be limited to machines
with a specific piece of hardware, and the attacker would need to expend
a significant amount of reverse engineering work on the firmware - and
we'd probably benefit from them doing that in the long run...
Now -- how about resuming from S4?

Reading stored memory image (potentially tampered before reboot) from disk
is basically DMA-ing arbitrary data over the whole RAM. I am currently not
able to imagine a scenario how this could be made "secure" (without
storing private keys to sign the hibernation image on the machine itself
which, well, doesn't sound secure either).
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Josh Boyer
2012-10-31 15:00:03 UTC
Permalink
Post by Jiri Kosina
Post by Matthew Garrett
Post by Jiri Kosina
This is pretty much identical to the first patchset, but with the capability
renamed (CAP_COMPROMISE_KERNEL) and the kexec patch dropped. If anyone wants
to deploy these then they should disable kexec until support for signed
kexec payloads has been merged.
Apparently your patchset currently doesn't handle device firmware loading,
nor do you seem to mention in in the comments.
Correct.
Post by Jiri Kosina
I believe signed firmware loading should be put on plate as well, right?
I think that's definitely something that should be covered. I hadn't
worried about it immediately as any attack would be limited to machines
with a specific piece of hardware, and the attacker would need to expend
a significant amount of reverse engineering work on the firmware - and
we'd probably benefit from them doing that in the long run...
Now -- how about resuming from S4?
Reading stored memory image (potentially tampered before reboot) from disk
is basically DMA-ing arbitrary data over the whole RAM. I am currently not
able to imagine a scenario how this could be made "secure" (without
storing private keys to sign the hibernation image on the machine itself
which, well, doesn't sound secure either).
I have a patch that disables that. I imagine it will be included in the
next submission of the patchset.

You can find it here in the meantime:

http://jwboyer.fedorapeople.org/pub/0001-hibernate-Disable-in-a-Secure-Boot-environment.patch

josh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Shea Levy
2012-10-31 15:10:02 UTC
Permalink
Post by Josh Boyer
Post by Jiri Kosina
Post by Matthew Garrett
Post by Jiri Kosina
This is pretty much identical to the first patchset, but with the capability
renamed (CAP_COMPROMISE_KERNEL) and the kexec patch dropped. If anyone wants
to deploy these then they should disable kexec until support for signed
kexec payloads has been merged.
Apparently your patchset currently doesn't handle device firmware loading,
nor do you seem to mention in in the comments.
Correct.
Post by Jiri Kosina
I believe signed firmware loading should be put on plate as well, right?
I think that's definitely something that should be covered. I hadn't
worried about it immediately as any attack would be limited to machines
with a specific piece of hardware, and the attacker would need to expend
a significant amount of reverse engineering work on the firmware - and
we'd probably benefit from them doing that in the long run...
Now -- how about resuming from S4?
Reading stored memory image (potentially tampered before reboot) from disk
is basically DMA-ing arbitrary data over the whole RAM. I am currently not
able to imagine a scenario how this could be made "secure" (without
storing private keys to sign the hibernation image on the machine itself
which, well, doesn't sound secure either).
I have a patch that disables that. I imagine it will be included in the
next submission of the patchset.
http://jwboyer.fedorapeople.org/pub/0001-hibernate-Disable-in-a-Secure-Boot-environment.patch
josh
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
More majordomo info at http://vger.kernel.org/majordomo-info.html
Perhaps this is overkill and too efi-specific, but on systems (like efi)
where there is firmware-manged storage that is protected from unsigned
access (e.g. efi vars), couldn't the kernel store a hash of the
hibernation image in that storage?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Alan Cox
2012-10-31 16:00:02 UTC
Permalink
Post by Josh Boyer
Post by Jiri Kosina
is basically DMA-ing arbitrary data over the whole RAM. I am currently not
able to imagine a scenario how this could be made "secure" (without
storing private keys to sign the hibernation image on the machine itself
which, well, doesn't sound secure either).
That's what the TPM is for (in fact all of this stuff can be done
properly with a TPM while the 'secure' boot stuff can do little if any of
it.
Post by Josh Boyer
I have a patch that disables that. I imagine it will be included in the
next submission of the patchset.
http://jwboyer.fedorapeople.org/pub/0001-hibernate-Disable-in-a-Secure-Boot-environment.patch
All this depends on your threat model. If I have physical access to
suspend/resume your machine then you already lost. If I don't have
physical access then I can't boot my unsigned OS to patch your S4 image
so it doesn't matter.

In fact the more I think about this the more it seems disabling hibernate
is basically farting in the wind.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Jiri Kosina
2012-10-31 16:00:02 UTC
Permalink
Post by Alan Cox
All this depends on your threat model. If I have physical access to
suspend/resume your machine then you already lost. If I don't have
physical access then I can't boot my unsigned OS to patch your S4 image
so it doesn't matter.
Prepare (as a root) a hand-crafted image, reboot, let the kernel resume
from that artificial image.

It can be viewed as a very obscure way of rewriting the kernel through
/dev/mem (which is obviously not possible when in 'secure boot'
environment).
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Alan Cox
2012-10-31 17:00:01 UTC
Permalink
On Wed, 31 Oct 2012 16:55:04 +0100 (CET)
Post by Jiri Kosina
Post by Alan Cox
All this depends on your threat model. If I have physical access to
suspend/resume your machine then you already lost. If I don't have
physical access then I can't boot my unsigned OS to patch your S4 image
so it doesn't matter.
Prepare (as a root) a hand-crafted image, reboot, let the kernel resume
from that artificial image.
It's not signed. It won't reboot from that image.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Shea Levy
2012-10-31 17:10:01 UTC
Permalink
Post by Alan Cox
On Wed, 31 Oct 2012 16:55:04 +0100 (CET)
Post by Jiri Kosina
Post by Alan Cox
All this depends on your threat model. If I have physical access to
suspend/resume your machine then you already lost. If I don't have
physical access then I can't boot my unsigned OS to patch your S4 image
so it doesn't matter.
Prepare (as a root) a hand-crafted image, reboot, let the kernel resume
from that artificial image.
It's not signed. It won't reboot from that image.
So then to hibernate the kernel must have a signing key?
Post by Alan Cox
Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Alan Cox
2012-10-31 17:20:02 UTC
Permalink
Post by Shea Levy
Post by Alan Cox
Post by Jiri Kosina
Prepare (as a root) a hand-crafted image, reboot, let the kernel resume
from that artificial image.
It's not signed. It won't reboot from that image.
So then to hibernate the kernel must have a signing key?
No.

If you break the kernel so you can patch swap we already lost.

If you add a new bootable image and reboot your image won't boot anyway

If you've got physical access you've already won

So you can't break the swap image before hibernation. You can't boot
something else to tamper with it and you've not got physical access.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Alan Cox
2012-10-31 17:20:02 UTC
Permalink
On Wed, 31 Oct 2012 17:10:48 +0000
Post by Alan Cox
On Wed, 31 Oct 2012 16:55:04 +0100 (CET)
Post by Jiri Kosina
Prepare (as a root) a hand-crafted image, reboot, let the kernel resume
from that artificial image.
It's not signed. It won't reboot from that image.
The kernel is signed. The kernel doesn't check the signature on the
suspend image.
Which doesn't matter. How are you going to create the tampered image in
the first place ?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Matthew Garrett
2012-10-31 17:20:02 UTC
Permalink
Post by Alan Cox
On Wed, 31 Oct 2012 17:10:48 +0000
The kernel is signed. The kernel doesn't check the signature on the
suspend image.
Which doesn't matter. How are you going to create the tampered image in
the first place ?
By booting a signed kernel, not turning on swap and writing directly to
the swap partition.
--
Matthew Garrett | ***@srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Alan Cox
2012-10-31 17:40:03 UTC
Permalink
On Wed, 31 Oct 2012 17:17:43 +0000
Post by Matthew Garrett
Post by Alan Cox
On Wed, 31 Oct 2012 17:10:48 +0000
The kernel is signed. The kernel doesn't check the signature on the
suspend image.
Which doesn't matter. How are you going to create the tampered image in
the first place ?
By booting a signed kernel, not turning on swap and writing directly to
the swap partition.
Ok so the actual problem is that you are signing kernels that allow the
user to skip the S4 resume check ?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Matthew Garrett
2012-10-31 17:40:04 UTC
Permalink
Post by Alan Cox
On Wed, 31 Oct 2012 17:17:43 +0000
Post by Matthew Garrett
By booting a signed kernel, not turning on swap and writing directly to
the swap partition.
Ok so the actual problem is that you are signing kernels that allow the
user to skip the S4 resume check ?
What S4 resume check?
--
Matthew Garrett | ***@srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Matthew Garrett
2012-10-31 17:50:02 UTC
Permalink
On Wed, 31 Oct 2012 17:37:50 +0000
Post by Matthew Garrett
What S4 resume check?
One you would add .. but no I'm wrong there - its a problem at the
suspend point so you do need a signature for it. Oh well yet another
reason it's nto useful.
Right. Hence the idea of a protected keystore at boot time. We can do
this securely, but it does involve writing code.
--
Matthew Garrett | ***@srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Alan Cox
2012-10-31 17:50:02 UTC
Permalink
On Wed, 31 Oct 2012 17:37:50 +0000
Post by Matthew Garrett
Post by Alan Cox
On Wed, 31 Oct 2012 17:17:43 +0000
Post by Matthew Garrett
By booting a signed kernel, not turning on swap and writing directly to
the swap partition.
Ok so the actual problem is that you are signing kernels that allow the
user to skip the S4 resume check ?
What S4 resume check?
One you would add .. but no I'm wrong there - its a problem at the
suspend point so you do need a signature for it. Oh well yet another
reason it's nto useful.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Oliver Neukum
2012-10-31 20:20:01 UTC
Permalink
Post by Alan Cox
On Wed, 31 Oct 2012 17:17:43 +0000
Post by Matthew Garrett
Post by Alan Cox
On Wed, 31 Oct 2012 17:10:48 +0000
The kernel is signed. The kernel doesn't check the signature on the
suspend image.
Which doesn't matter. How are you going to create the tampered image in
the first place ?
By booting a signed kernel, not turning on swap and writing directly to
the swap partition.
Ok so the actual problem is that you are signing kernels that allow the
user to skip the S4 resume check ?
No. The problem is principal in nature.

swapoff /dev/sdb6 ; dd if=/tmp/malicious_image of=/dev/sdb6 ; sync ; reboot

That would do it on my system.
Maybe in theory you could solve this by the kernel invalidating images
it hasn't written itself and forbidding to change the resume partition from the
kernel command line, but that would break user space hibernation.

Regards
Oliver

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Chris Friesen
2012-10-31 22:00:02 UTC
Permalink
Post by Oliver Neukum
Post by Alan Cox
On Wed, 31 Oct 2012 17:17:43 +0000
Post by Matthew Garrett
Post by Alan Cox
On Wed, 31 Oct 2012 17:10:48 +0000
The kernel is signed. The kernel doesn't check the signature on the
suspend image.
Which doesn't matter. How are you going to create the tampered image in
the first place ?
By booting a signed kernel, not turning on swap and writing directly to
the swap partition.
Ok so the actual problem is that you are signing kernels that allow the
user to skip the S4 resume check ?
No. The problem is principal in nature.
swapoff /dev/sdb6 ; dd if=/tmp/malicious_image of=/dev/sdb6 ; sync ; reboot
That would do it on my system.
Maybe in theory you could solve this by the kernel invalidating images
it hasn't written itself and forbidding to change the resume partition from the
kernel command line, but that would break user space hibernation.
If the resuming kernel refuses to resume from images it didn't create
itself, why do you need to forbid changing the resume partition from the
kernel command line?

Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Jiri Kosina
2012-10-31 22:10:01 UTC
Permalink
Post by Oliver Neukum
That would do it on my system.
Maybe in theory you could solve this by the kernel invalidating images
it hasn't written itself and forbidding to change the resume partition from the
kernel command line, but that would break user space hibernation.
If the resuming kernel refuses to resume from images it didn't create itself,
why do you need to forbid changing the resume partition from the kernel
command line?
Yeah, it can definitely be solved by pushing keys around from shim to
kernel (and kernel discarding the private keys at right moments). It just
needs to be implemented.
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Oliver Neukum
2012-10-31 22:20:01 UTC
Permalink
Post by Chris Friesen
Post by Oliver Neukum
That would do it on my system.
Maybe in theory you could solve this by the kernel invalidating images
it hasn't written itself and forbidding to change the resume partition from the
kernel command line, but that would break user space hibernation.
If the resuming kernel refuses to resume from images it didn't create
itself, why do you need to forbid changing the resume partition from the
kernel command line?
You don't. Signed images solve the problem.

I was responding to Alan's assertation that the problem could be solved
without signing the images. It turns out tht any such scheme would have
unacceptable limitations.

The key problem is actually safely storing the public key needed to verify
the signature. This problem is also solvable. It just needs help from the
UEFI infrastructure.

Regards
Oliver

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
James Bottomley
2012-11-01 09:10:02 UTC
Permalink
Post by Oliver Neukum
Post by Chris Friesen
Post by Oliver Neukum
That would do it on my system.
Maybe in theory you could solve this by the kernel invalidating images
it hasn't written itself and forbidding to change the resume partition from the
kernel command line, but that would break user space hibernation.
If the resuming kernel refuses to resume from images it didn't create
itself, why do you need to forbid changing the resume partition from the
kernel command line?
You don't. Signed images solve the problem.
I really don't think they do. The proposed attack vector is to try to
prevent a local root exploit from running arbitrary in-kernel code,
because that would compromise the secure boot part of the kernel.

I really think that's mythical: a local privilege elevation attack
usually exploits some bug (classically a buffer overflow) which executes
arbitrary code in kernel context. In that case, the same attack vector
can be used to compromise any in-kernel protection mechanism including
turning off the secure boot capability and reading the in-kernel private
signing key.

There have been one or two privilege elevation attacks that didn't
involve in-kernel code (usually by compromising a suid binary or other
cross domain scripting attack) that would only compromise local root and
thus be confined to the secure boot prison but they are, historically, a
minority.

The point I'm making is that given that the majority of exploits will
already be able to execute arbitrary code in-kernel, there's not much
point trying to consider features like this as attacker prevention. We
should really be focusing on discussing why we'd want to prevent a
legitimate local root from writing to the suspend partition in a secure
boot environment.

James


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Jiri Kosina
2012-11-01 09:30:01 UTC
Permalink
Post by James Bottomley
The point I'm making is that given that the majority of exploits will
already be able to execute arbitrary code in-kernel, there's not much
point trying to consider features like this as attacker prevention. We
should really be focusing on discussing why we'd want to prevent a
legitimate local root from writing to the suspend partition in a secure
boot environment.
Well, this is being repeated over and over again when talking about secure
boot, right?

My understanding is that we are not trying to protect against root
exploiting the kernel. We are trying to protect against root tampering
with the kernel code and data through legitimate use of kernel-provided
facilitiies (/dev/mem, ioperm, reprogramming devices to DMA to arbitrary
memory locations, resuming from hibernation image that has been tampered
with, etc).

Or perhaps I just misunderstood the point you were trying to make?

Thanks,
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
James Bottomley
2012-11-01 09:40:01 UTC
Permalink
Post by Jiri Kosina
Post by James Bottomley
The point I'm making is that given that the majority of exploits will
already be able to execute arbitrary code in-kernel, there's not much
point trying to consider features like this as attacker prevention. We
should really be focusing on discussing why we'd want to prevent a
legitimate local root from writing to the suspend partition in a secure
boot environment.
Well, this is being repeated over and over again when talking about secure
boot, right?
My understanding is that we are not trying to protect against root
exploiting the kernel. We are trying to protect against root tampering
with the kernel code and data through legitimate use of kernel-provided
facilitiies (/dev/mem, ioperm, reprogramming devices to DMA to arbitrary
memory locations, resuming from hibernation image that has been tampered
with, etc).
Or perhaps I just misunderstood the point you were trying to make?
I'm actually just struggling to understand the use case for these more
esoteric protections.

So the assumption is malice on the part of a legitimate local root? I
just don't see what such a user would gain by compromising resume in
this way (given that their scope for damage in the rest of the system
and data is huge) and I don't really see why a non-malicious local root
would be interested. A legitimate local root entails quite a measure of
trust, so what I don't really see is the use case for investing all that
trust in someone but not trusting them with the boot system. In a
proper capability separated limited trust environment, you simply don't
allow less trusted users raw access to all or some devices and that
solves the problem far more simply.

James


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Jiri Kosina
2012-11-01 09:50:02 UTC
Permalink
Post by James Bottomley
I'm actually just struggling to understand the use case for these more
esoteric protections.
I believe the real point is drawing a clear line between trusted and
untrusted (with root being userspace, hence implicitly untrusted), and
disallowing "legitimate crossing" of this line.
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
James Bottomley
2012-11-01 10:00:01 UTC
Permalink
Post by Jiri Kosina
Post by James Bottomley
I'm actually just struggling to understand the use case for these more
esoteric protections.
I believe the real point is drawing a clear line between trusted and
untrusted (with root being userspace, hence implicitly untrusted), and
disallowing "legitimate crossing" of this line.
But that doesn't really help me: untrusted root is an oxymoron. I get
capability separated systems, where you invest trust in layers and you
make each layer small and verifiable, so you have a granular trust
policy you build up. I really don't understand the use case for trying
to remove a small portion of trust from the huge trust domain of root
and then doing a massive amount of fixup around the edges because
there's leaks all over the place from the trust that root still has. It
all seems to be a bit backwards. If you just begin with the capability
separated granular system, I don't see why it doesn't all just work with
what we have today.

James


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Jiri Kosina
2012-11-01 10:10:02 UTC
Permalink
Post by James Bottomley
Post by Jiri Kosina
Post by James Bottomley
I'm actually just struggling to understand the use case for these more
esoteric protections.
I believe the real point is drawing a clear line between trusted and
untrusted (with root being userspace, hence implicitly untrusted), and
disallowing "legitimate crossing" of this line.
But that doesn't really help me: untrusted root is an oxymoron. I get
capability separated systems, where you invest trust in layers and you
make each layer small and verifiable, so you have a granular trust
policy you build up. I really don't understand the use case for trying
to remove a small portion of trust from the huge trust domain of root
and then doing a massive amount of fixup around the edges because
there's leaks all over the place from the trust that root still has. It
all seems to be a bit backwards. If you just begin with the capability
separated granular system, I don't see why it doesn't all just work with
what we have today.
Please don't get me wrong -- I personally don't believe in the secure boot
stuff at all.

But if you take the secure/trusted boot as a basic paradigma, then you
really need the separation.
In such model, the root is untrusted, exactly because the code running
under those privileges hasn't been signed, period. If you allow such code
to modify the trusted/signed code, you just basically violate the complete
model, rendering it completely moot.
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Eric Paris
2012-11-01 14:30:02 UTC
Permalink
On Thu, Nov 1, 2012 at 5:59 AM, James Bottomley
Post by James Bottomley
But that doesn't really help me: untrusted root is an oxymoron.
Imagine you run windows and you've never heard of Linux. You like
that only windows kernels can boot on your box and not those mean
nasty hacked up malware kernels. Now some attacker manages to take
over your box because you clicked on that executable for young models
in skimpy bathing suits. That executable rewrote your bootloader to
launch a very small carefully crafted Linux environment. This
environment does nothing but launch a perfectly valid signed Linux
kernel, which gets a Windows environment all ready to launch after
resume and goes to sleep. Now you have to hit the power button twice
every time you turn on your computer, weird, but Windows comes up, and
secureboot is still on, so you must be safe!

In this case we have a completely 'untrusted' root inside Linux. From
the user PoV root and Linux are both malware. Notice the EXACT same
attack would work launching rootkit'd Linux from Linux. So don't
pretend not to care about Windows. It's just that launching malware
Linux seems like a reason to get your key revoked. We don't want
signed code which can be used as an attack vector on ourselves or on
others.

That make sense?

-Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
James Bottomley
2012-11-01 14:50:03 UTC
Permalink
Post by Eric Paris
On Thu, Nov 1, 2012 at 5:59 AM, James Bottomley
Post by James Bottomley
But that doesn't really help me: untrusted root is an oxymoron.
Imagine you run windows and you've never heard of Linux. You like
that only windows kernels can boot on your box and not those mean
nasty hacked up malware kernels. Now some attacker manages to take
over your box because you clicked on that executable for young models
in skimpy bathing suits. That executable rewrote your bootloader to
launch a very small carefully crafted Linux environment. This
environment does nothing but launch a perfectly valid signed Linux
kernel, which gets a Windows environment all ready to launch after
resume and goes to sleep. Now you have to hit the power button twice
every time you turn on your computer, weird, but Windows comes up, and
secureboot is still on, so you must be safe!
So you're going back to the root exploit problem? I thought that was
debunked a few emails ago in the thread?

Your attack vector isn't plausible because for the suspend attack to
work, the box actually has to be running Linux by default ... I think
the admin of that box might notice if it suddenly started running
windows ...
Post by Eric Paris
In this case we have a completely 'untrusted' root inside Linux. From
the user PoV root and Linux are both malware. Notice the EXACT same
attack would work launching rootkit'd Linux from Linux. So don't
pretend not to care about Windows. It's just that launching malware
Linux seems like a reason to get your key revoked. We don't want
signed code which can be used as an attack vector on ourselves or on
others.
That make sense?
Not really, no. A windows attack vector is a pointless abstraction
because we're talking about securing Linux and your vector requires a
Linux attack for the windows compromise ... let's try to keep on point
to how we're using this feature to secure Linux.

James


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Matthew Garrett
2012-11-01 14:50:03 UTC
Permalink
Post by James Bottomley
Post by Eric Paris
Imagine you run windows and you've never heard of Linux. You like
that only windows kernels can boot on your box and not those mean
nasty hacked up malware kernels. Now some attacker manages to take
over your box because you clicked on that executable for young models
in skimpy bathing suits. That executable rewrote your bootloader to
launch a very small carefully crafted Linux environment. This
environment does nothing but launch a perfectly valid signed Linux
kernel, which gets a Windows environment all ready to launch after
resume and goes to sleep. Now you have to hit the power button twice
every time you turn on your computer, weird, but Windows comes up, and
secureboot is still on, so you must be safe!
So you're going back to the root exploit problem? I thought that was
debunked a few emails ago in the thread?
The entire point of this feature is that it's no longer possible to turn
a privileged user exploit into a full system exploit. Gaining admin
access on Windows 8 doesn't permit you to install a persistent backdoor,
unless there's some way to circumvent that. Which there is, if you can
drop a small Linux distribution onto the ESP and use a signed, trusted
bootloader to boot a signed, trusted kernel that then resumes from an
unsigned, untrusted hibernate image. So we have to ensure that that's
impossible.
--
Matthew Garrett | ***@srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Alan Cox
2012-11-01 15:10:02 UTC
Permalink
Post by Matthew Garrett
The entire point of this feature is that it's no longer possible to turn
a privileged user exploit into a full system exploit. Gaining admin
access on Windows 8 doesn't permit you to install a persistent backdoor,
Really, that would be a first. Do you have a detailed knowledge of
windows 8 actual security ?
Post by Matthew Garrett
unless there's some way to circumvent that. Which there is, if you can
drop a small Linux distribution onto the ESP and use a signed, trusted
bootloader to boot a signed, trusted kernel that then resumes from an
unsigned, untrusted hibernate image. So we have to ensure that that's
impossible.
Well if you want to make Linux entirely robust Red Hat could start
helping with some of the 6000 odd coverity matches some of which will
most certainly turn out to be real flaws.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Matthew Garrett
2012-11-01 16:30:01 UTC
Permalink
Post by Alan Cox
Post by Matthew Garrett
The entire point of this feature is that it's no longer possible to turn
a privileged user exploit into a full system exploit. Gaining admin
access on Windows 8 doesn't permit you to install a persistent backdoor,
Really, that would be a first. Do you have a detailed knowledge of
windows 8 actual security ?
http://msdn.microsoft.com/en-us/library/windows/desktop/hh848061%28v=vs.85%29.aspx
Post by Alan Cox
Post by Matthew Garrett
unless there's some way to circumvent that. Which there is, if you can
drop a small Linux distribution onto the ESP and use a signed, trusted
bootloader to boot a signed, trusted kernel that then resumes from an
unsigned, untrusted hibernate image. So we have to ensure that that's
impossible.
Well if you want to make Linux entirely robust Red Hat could start
helping with some of the 6000 odd coverity matches some of which will
most certainly turn out to be real flaws.
Sure, bugs should be fixed.
--
Matthew Garrett | ***@srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Alan Cox
2012-11-01 16:40:02 UTC
Permalink
On Thu, 1 Nov 2012 16:29:01 +0000
Post by Matthew Garrett
Post by Alan Cox
Post by Matthew Garrett
The entire point of this feature is that it's no longer possible to turn
a privileged user exploit into a full system exploit. Gaining admin
access on Windows 8 doesn't permit you to install a persistent backdoor,
Really, that would be a first. Do you have a detailed knowledge of
windows 8 actual security ?
http://msdn.microsoft.com/en-us/library/windows/desktop/hh848061%28v=vs.85%29.aspx
No I said knowledge of not web pages. The Red Hat pages say Linux is very
secure, the Apple ones say MacOS is.

The point being you don't want to evaluate apparent security by press
release of one system versus deep internal knowledge of the other.

Alan


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
James Bottomley
2012-11-01 15:10:02 UTC
Permalink
Post by Matthew Garrett
Post by James Bottomley
Post by Eric Paris
Imagine you run windows and you've never heard of Linux. You like
that only windows kernels can boot on your box and not those mean
nasty hacked up malware kernels. Now some attacker manages to take
over your box because you clicked on that executable for young models
in skimpy bathing suits. That executable rewrote your bootloader to
launch a very small carefully crafted Linux environment. This
environment does nothing but launch a perfectly valid signed Linux
kernel, which gets a Windows environment all ready to launch after
resume and goes to sleep. Now you have to hit the power button twice
every time you turn on your computer, weird, but Windows comes up, and
secureboot is still on, so you must be safe!
So you're going back to the root exploit problem? I thought that was
debunked a few emails ago in the thread?
The entire point of this feature is that it's no longer possible to turn
a privileged user exploit into a full system exploit. Gaining admin
access on Windows 8 doesn't permit you to install a persistent backdoor,
unless there's some way to circumvent that. Which there is, if you can
drop a small Linux distribution onto the ESP and use a signed, trusted
bootloader to boot a signed, trusted kernel that then resumes from an
unsigned, untrusted hibernate image. So we have to ensure that that's
impossible.
But surely that's fanciful ... you've already compromised windows to get
access to the ESP. If you've done it once, you can do it again until
the exploit is patched. There are likely many easier ways of ensuring
persistence than trying to install a full linux kernel with a
compromised resume system.

If this could be used to attack a windows system in the first place,
then Microsoft might be annoyed, but you have to compromise windows
*first* in this scenario.

James


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Eric Paris
2012-11-01 15:20:01 UTC
Permalink
On Thu, Nov 1, 2012 at 11:06 AM, James Bottomley
Post by James Bottomley
But surely that's fanciful ... you've already compromised windows to get
access to the ESP. If you've done it once, you can do it again until
the exploit is patched.
You work under the assumption that any bad operation was done by means
of a compromised kernel. Admins install things all the time,
sometimes, things which they shouldn't. (This statement is OS
agnostic)
Post by James Bottomley
There are likely many easier ways of ensuring
persistence than trying to install a full linux kernel with a
compromised resume system.
I'm sure lots of us would love to hear the ideas. And the attack is
on the suspend side, nothing about resume has to be malicious (not
really relevant I guess)...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Matthew Garrett
2012-11-01 16:30:01 UTC
Permalink
Post by James Bottomley
But surely that's fanciful ... you've already compromised windows to get
access to the ESP. If you've done it once, you can do it again until
the exploit is patched. There are likely many easier ways of ensuring
persistence than trying to install a full linux kernel with a
compromised resume system.
There's a pretty strong distinction between "Machine is exploited until
exploit is patched" and "Machine is exploited until drive is replaced".
--
Matthew Garrett | ***@srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Eric Paris
2012-11-01 15:00:02 UTC
Permalink
On Thu, Nov 1, 2012 at 10:42 AM, James Bottomley
Post by James Bottomley
Post by Eric Paris
On Thu, Nov 1, 2012 at 5:59 AM, James Bottomley
Post by James Bottomley
But that doesn't really help me: untrusted root is an oxymoron.
Imagine you run windows and you've never heard of Linux. You like
that only windows kernels can boot on your box and not those mean
nasty hacked up malware kernels. Now some attacker manages to take
over your box because you clicked on that executable for young models
in skimpy bathing suits. That executable rewrote your bootloader to
launch a very small carefully crafted Linux environment. This
environment does nothing but launch a perfectly valid signed Linux
kernel, which gets a Windows environment all ready to launch after
resume and goes to sleep. Now you have to hit the power button twice
every time you turn on your computer, weird, but Windows comes up, and
secureboot is still on, so you must be safe!
So you're going back to the root exploit problem? I thought that was
debunked a few emails ago in the thread?
Your attack vector isn't plausible because for the suspend attack to
work, the box actually has to be running Linux by default ... I think
the admin of that box might notice if it suddenly started running
windows ...
Maybe you misread. The owner of the box would never know a shim Linux
was loaded. In any case, as I said, windows really is irrelevant.
It's just using Linux as an attack vectore against Windows is what
would get keys revoked. If your key is revoke Linux can't boot on a
large amount of new hardware without BIOS twiddling.u
Post by James Bottomley
Post by Eric Paris
In this case we have a completely 'untrusted' root inside Linux. From
the user PoV root and Linux are both malware. Notice the EXACT same
attack would work launching rootkit'd Linux from Linux. So don't
pretend not to care about Windows. It's just that launching malware
Linux seems like a reason to get your key revoked. We don't want
signed code which can be used as an attack vector on ourselves or on
others.
That make sense?
Not really, no. A windows attack vector is a pointless abstraction
because we're talking about securing Linux and your vector requires a
Linux attack for the windows compromise ... let's try to keep on point
to how we're using this feature to secure Linux.
I pointed out that the exact same attack exists with Linux on Linux.
To launch a malware linux kernel all you have to do is launch a shim
signed acceptable linux environment, have it set up the malware kernel
to launch after resume, and go to sleep. Agreed, it'd be very weird
that the first time you hit the power button your machine comes on and
then quickly goes right back to sleep, but certainly we can envision
that being ignored by many desktop users...

Do you see how 'root' in the first environment is untrusted? Now you
can pretend not to care because the 'original' root was trusted. But
people install bad crap all the time. There are hundreds of ways to
install bad software as root. Go to any site distributing rpms or
debs to get that new version of mod_perl and it could install the
malware kernel and shim environment.

The point of secureboot is even if the admin did something which
allowed his kernel to be compromised, it won't persist. Sure,
secureboot moves the attack up the stack to userspace, but at least we
can do something about the kernel.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Alan Cox
2012-11-01 15:10:02 UTC
Permalink
Post by Eric Paris
would get keys revoked. If your key is revoke Linux can't boot on a
large amount of new hardware without BIOS twiddling.
See "live free or die". If you want to live in a world where you can't
even fart before checking if the man from Microsoft will revoke your key
you might as well go home now.
Post by Eric Paris
The point of secureboot is even if the admin did something which
allowed his kernel to be compromised, it won't persist. Sure,
secureboot moves the attack up the stack to userspace, but at least we
can do something about the kernel.
Nice theory.

At the end of the day I don't care if you want to produce this stuff and
sell it to people. Fine, the interface proposed is clean enough that it
doesn't pee on other work, but don't expect the rest of the world to
follow mindlessly into your slave pit driven by your fear.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
James Bottomley
2012-11-01 15:20:02 UTC
Permalink
Post by Eric Paris
On Thu, Nov 1, 2012 at 10:42 AM, James Bottomley
Post by James Bottomley
Post by Eric Paris
On Thu, Nov 1, 2012 at 5:59 AM, James Bottomley
Post by James Bottomley
But that doesn't really help me: untrusted root is an oxymoron.
Imagine you run windows and you've never heard of Linux. You like
that only windows kernels can boot on your box and not those mean
nasty hacked up malware kernels. Now some attacker manages to take
over your box because you clicked on that executable for young models
in skimpy bathing suits. That executable rewrote your bootloader to
launch a very small carefully crafted Linux environment. This
environment does nothing but launch a perfectly valid signed Linux
kernel, which gets a Windows environment all ready to launch after
resume and goes to sleep. Now you have to hit the power button twice
every time you turn on your computer, weird, but Windows comes up, and
secureboot is still on, so you must be safe!
So you're going back to the root exploit problem? I thought that was
debunked a few emails ago in the thread?
Your attack vector isn't plausible because for the suspend attack to
work, the box actually has to be running Linux by default ... I think
the admin of that box might notice if it suddenly started running
windows ...
Maybe you misread. The owner of the box would never know a shim Linux
was loaded. In any case, as I said, windows really is irrelevant.
It's just using Linux as an attack vectore against Windows is what
would get keys revoked. If your key is revoke Linux can't boot on a
large amount of new hardware without BIOS twiddling.u
Post by James Bottomley
Post by Eric Paris
In this case we have a completely 'untrusted' root inside Linux. From
the user PoV root and Linux are both malware. Notice the EXACT same
attack would work launching rootkit'd Linux from Linux. So don't
pretend not to care about Windows. It's just that launching malware
Linux seems like a reason to get your key revoked. We don't want
signed code which can be used as an attack vector on ourselves or on
others.
That make sense?
Not really, no. A windows attack vector is a pointless abstraction
because we're talking about securing Linux and your vector requires a
Linux attack for the windows compromise ... let's try to keep on point
to how we're using this feature to secure Linux.
I pointed out that the exact same attack exists with Linux on Linux.
To launch a malware linux kernel all you have to do is launch a shim
signed acceptable linux environment, have it set up the malware kernel
to launch after resume, and go to sleep. Agreed, it'd be very weird
that the first time you hit the power button your machine comes on and
then quickly goes right back to sleep, but certainly we can envision
that being ignored by many desktop users...
Do you see how 'root' in the first environment is untrusted? Now you
can pretend not to care because the 'original' root was trusted. But
people install bad crap all the time. There are hundreds of ways to
install bad software as root. Go to any site distributing rpms or
debs to get that new version of mod_perl and it could install the
malware kernel and shim environment.
You're completely confusing two separate goals:

1. Is it possible to use secure boot to implement a security policy
on Linux
2. What do we have to do anything to prevent Linux being used to
attack windows which may lead to a revocation of the distro
signing key.

"untrusted root" is a silly answer to 1 because it's incredibly
difficult to remove sufficient trust from root and still have it be
trusted enough to be effective as root. The trust bound up in root is
incredibly intertwined. It would be far better to start by eliminating
the root user altogether and building up on the capabilities in a
granular fashion for this type of lockdown.

"untrusted root", if it can even be achieved, might be a sufficient
condition for 2 but it's way overkill for a necessary one.

James


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Eric Paris
2012-11-01 18:00:02 UTC
Permalink
On Thu, Nov 1, 2012 at 11:18 AM, James Bottomley
Post by James Bottomley
1. Is it possible to use secure boot to implement a security policy
on Linux
2. What do we have to do anything to prevent Linux being used to
attack windows which may lead to a revocation of the distro
signing key.
"untrusted root" is a silly answer to 1 because it's incredibly
difficult to remove sufficient trust from root and still have it be
trusted enough to be effective as root. The trust bound up in root is
incredibly intertwined. It would be far better to start by eliminating
the root user altogether and building up on the capabilities in a
granular fashion for this type of lockdown.
granular lockdown!? sounds like SELinux. But that certainly can't
solve the problems here...

I think your premise has a couple of problems. First is how you chose
to word #2. Lets reword it as:

What do we have to do to prevent Linux being used to attack Linux
which may lead to secure boot being useless.

If we accept that as #2, then we think, "What makes secure boot
useless" or "What is the security goal as envisioned by secure boot."
The goal of secure boot is to implement an operating system which
prevents uid==0 to ring 0 escalation. That is the security policy
secure boot needs to not be completely useless. And as it turns out,
that security policy is useful in other situations.
Post by James Bottomley
"untrusted root", if it can even be achieved, might be a sufficient
condition for 2 but it's way overkill for a necessary one.
But it is a condition, as specifically stated, that others have wanted
long before secure boot even came to rise. I've talked with and
worked with a public cloud operator who wants to prevent even a
malicious root user from being able to run code in ring 0 inside their
VM. The hope in that case was that in doing so they can indirectly
shrink the attack surface between virtual machine and hypervisor.
They hoped to limit the ways the guest could interact to only those
methods the linux kernel implemented.

They want to launch a vm running a kernel they chose and make sure
root inside the vm could not run some other kernel or run arbitrary
code in kernel space. It's wasn't something they solved completely.
If it was, all of this secure boot work would be finished. Which is
why we are having these discussions to understand all of the way that
you an Alan seem to have to get around the secure boot restrictions.
And look for solutions to retain functionality which meeting the
security goal of 'prevent uid=0 to ring 0 privilege escalation.

-Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Matthew Garrett
2012-11-01 21:10:02 UTC
Permalink
Post by Eric Paris
What do we have to do to prevent Linux being used to attack Linux
which may lead to secure boot being useless.
That's not really remotely related, is it? Microsoft doesn't really
care about Linux on Linux attacks, so preventing or allowing them isn't
going to get a distro key revoked.
Linux vendors may care about Linux on Linux attacks. It's all fun and
games until Oracle get Microsoft to revoke Red Hat's signature.
--
Matthew Garrett | ***@srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Matthew Garrett
2012-11-01 21:20:02 UTC
Permalink
I agree that's a possibility. However, I think the court of public
opinion would pillory the first Commercial Linux Distribution that went
to Microsoft for the express purpose of revoking their competition's
right to boot. It would be commercial suicide.
Oracle are something of a vexatious litigant as far as the court of
public opinion is concerned, but even without that it could be a
customer who complains. If you're personally comfortable with a specific
level of security here, that's fine - but it's completely reasonable for
others to feel that there are valid technical and commercial concerns to
do this properly.
--
Matthew Garrett | ***@srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Alan Cox
2012-11-01 21:40:03 UTC
Permalink
On Thu, 1 Nov 2012 21:18:59 +0000
Post by Matthew Garrett
I agree that's a possibility. However, I think the court of public
opinion would pillory the first Commercial Linux Distribution that went
to Microsoft for the express purpose of revoking their competition's
right to boot. It would be commercial suicide.
Oracle are something of a vexatious litigant as far as the court of
public opinion is concerned, but even without that it could be a
customer who complains. If you're personally comfortable with a specific
level of security here, that's fine - but it's completely reasonable for
others to feel that there are valid technical and commercial concerns to
do this properly.
The main people who really really care about this the MS key stuff
is mostly irrelevant for as they won't use the Microsoft keys
anyway. Microsoft will have to provide signing to all sorts of other law
enforcement bodies as a responsible provider. If the FBI have a key no
other government security installation will have that key in their
systems. If the Chinese state has it I doubt the US government will be
too keen either.

All those official government trojans end up creating a big problem in the
trust department.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
James Bottomley
2012-11-01 21:20:02 UTC
Permalink
Post by Matthew Garrett
Post by Eric Paris
What do we have to do to prevent Linux being used to attack Linux
which may lead to secure boot being useless.
That's not really remotely related, is it? Microsoft doesn't really
care about Linux on Linux attacks, so preventing or allowing them isn't
going to get a distro key revoked.
Linux vendors may care about Linux on Linux attacks. It's all fun and
games until Oracle get Microsoft to revoke Red Hat's signature.
I agree that's a possibility. However, I think the court of public
opinion would pillory the first Commercial Linux Distribution that went
to Microsoft for the express purpose of revoking their competition's
right to boot. It would be commercial suicide.

James



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Alan Cox
2012-11-01 21:30:02 UTC
Permalink
Post by Matthew Garrett
Linux vendors may care about Linux on Linux attacks. It's all fun and
games until Oracle get Microsoft to revoke Red Hat's signature.
Fear uncertainty and doubt (and if you think Oracle are going to do that
I suspect your lawyers should deal with it)

Alan.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Matthew Garrett
2012-11-01 21:30:03 UTC
Permalink
Post by Alan Cox
Post by Matthew Garrett
Linux vendors may care about Linux on Linux attacks. It's all fun and
games until Oracle get Microsoft to revoke Red Hat's signature.
Fear uncertainty and doubt (and if you think Oracle are going to do that
I suspect your lawyers should deal with it)
Lawyers won't remove blacklist entries.
--
Matthew Garrett | ***@srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Alan Cox
2012-11-01 21:40:03 UTC
Permalink
On Thu, 1 Nov 2012 21:28:43 +0000
Post by Matthew Garrett
Post by Alan Cox
Post by Matthew Garrett
Linux vendors may care about Linux on Linux attacks. It's all fun and
games until Oracle get Microsoft to revoke Red Hat's signature.
Fear uncertainty and doubt (and if you think Oracle are going to do that
I suspect your lawyers should deal with it)
Lawyers won't remove blacklist entries.
Fear Uncertainty and Doubt

Courts do, injunctions do, the possibilty of getting caught with theirs
hands in the till does.

But I suspect your lawyers should also deal with public comments about
Oracle such as the one you've made before you make them in public 8)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Matthew Garrett
2012-11-01 21:40:04 UTC
Permalink
Post by Alan Cox
On Thu, 1 Nov 2012 21:28:43 +0000
Post by Matthew Garrett
Lawyers won't remove blacklist entries.
Fear Uncertainty and Doubt
Courts do, injunctions do, the possibilty of getting caught with theirs
hands in the till does.
I think you've misunderstood. Blacklist updates are append only.
--
Matthew Garrett | ***@srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Matthew Garrett
2012-11-01 22:00:01 UTC
Permalink
On Thu, 1 Nov 2012 21:34:52 +0000
Post by Matthew Garrett
I think you've misunderstood. Blacklist updates are append only.
I think you've misunderstood - thats a technical detail that merely
alters the cost to the people who did something improper.
Winning a case is cold comfort if your software has been uninstallable
for the years it took to get through the courts. If others want to take
that risk, fine.
--
Matthew Garrett | ***@srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Eric W. Biederman
2012-11-02 08:50:01 UTC
Permalink
Post by Matthew Garrett
On Thu, 1 Nov 2012 21:34:52 +0000
Post by Matthew Garrett
I think you've misunderstood. Blacklist updates are append only.
I think you've misunderstood - thats a technical detail that merely
alters the cost to the people who did something improper.
Winning a case is cold comfort if your software has been uninstallable
for the years it took to get through the courts. If others want to take
that risk, fine.
When the goal is to secure Linux I don't see how any of this helps.
Windows 8 compromises are already available so if we turn most of these
arguments around I am certain clever attackers can go through windows to
run compromised kernel on a linux system, at least as easily as the
reverse.

Short of instructing UEFI to stop trusting the Microsoft signing key I
don't see any of the secureboot dance gaining any security of computers
running linux or security from keys being revoked for non-sense reasons.

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Matthew Garrett
2012-11-02 14:10:03 UTC
Permalink
Post by Eric W. Biederman
When the goal is to secure Linux I don't see how any of this helps.
Windows 8 compromises are already available so if we turn most of these
arguments around I am certain clever attackers can go through windows to
run compromised kernel on a linux system, at least as easily as the
reverse.
And if any of them are used to attack Linux, we'd expect those versions
of Windows to be blacklisted.
--
Matthew Garrett | ***@srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Alan Cox
2012-11-01 22:00:02 UTC
Permalink
On Thu, 1 Nov 2012 21:34:52 +0000
Post by Matthew Garrett
Post by Alan Cox
On Thu, 1 Nov 2012 21:28:43 +0000
Post by Matthew Garrett
Lawyers won't remove blacklist entries.
Fear Uncertainty and Doubt
Courts do, injunctions do, the possibilty of getting caught with theirs
hands in the till does.
I think you've misunderstood. Blacklist updates are append only.
I think you've misunderstood - thats a technical detail that merely
alters the cost to the people who did something improper.

If Red Hat want to ship a kernel that is very very locked down - fine.
It's a business choice and maybe it'll sell to someone. The
implementation is non-offensive in its mechanism for everyone else so
technically I don't care, but the 'quiver before our new masters and lick
their boots' stuff isn't a technical (or sane business) approach so can
we cut the trying to FUD other people into doing what you believe your
new master requires.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
James Bottomley
2012-11-01 21:10:02 UTC
Permalink
Post by Eric Paris
On Thu, Nov 1, 2012 at 11:18 AM, James Bottomley
Post by James Bottomley
1. Is it possible to use secure boot to implement a security policy
on Linux
2. What do we have to do anything to prevent Linux being used to
attack windows which may lead to a revocation of the distro
signing key.
"untrusted root" is a silly answer to 1 because it's incredibly
difficult to remove sufficient trust from root and still have it be
trusted enough to be effective as root. The trust bound up in root is
incredibly intertwined. It would be far better to start by eliminating
the root user altogether and building up on the capabilities in a
granular fashion for this type of lockdown.
granular lockdown!? sounds like SELinux. But that certainly can't
solve the problems here...
I think your premise has a couple of problems. First is how you chose
What do we have to do to prevent Linux being used to attack Linux
which may lead to secure boot being useless.
That's not really remotely related, is it? Microsoft doesn't really
care about Linux on Linux attacks, so preventing or allowing them isn't
going to get a distro key revoked.
Post by Eric Paris
If we accept that as #2, then we think, "What makes secure boot
useless" or "What is the security goal as envisioned by secure boot."
The goal of secure boot is to implement an operating system which
prevents uid==0 to ring 0 escalation. That is the security policy
secure boot needs to not be completely useless. And as it turns out,
that security policy is useful in other situations.
Um, so all that is a rewording of what I said in 1 ... how do you take
advantage of secure boot, so you're re-conflating the issues.

Snip the rest because it doesn't really make sense in terms of getting
the key revoked.

James


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Alan Cox
2012-11-01 14:50:02 UTC
Permalink
Post by Eric Paris
Imagine you run windows and you've never heard of Linux.
To those people I think you mean "never heard of Ubuntu" ;-)
Post by Eric Paris
In this case we have a completely 'untrusted' root inside Linux. From
the user PoV root and Linux are both malware. Notice the EXACT same
attack would work launching rootkit'd Linux from Linux. So don't
pretend not to care about Windows. It's just that launching malware
Linux seems like a reason to get your key revoked. We don't want
signed code which can be used as an attack vector on ourselves or on
others.
That make sense?
Not really but it keeps some of the Red Hat security people happy and out
of harms way. With all the current posted RH patches I can still take over
the box as root trivially enough and you seem to have so far abolished
suspend to disk, kexec and a pile of other useful stuff. To actually lock
it down you'll have to do a ton more of this. I suspect folks who know
windows innards well are probably thinking the same about Windows 8 8)

Almost anyone attacking a secure boot box will do it via windows or more
likely via EFI. EFI because its large, new and doesn't a great history,
windows because its the larger target. Actually from what I've seen on
the security front there seems to a distinct view that secure boot is
irrelevant because Windows 8 is so suspend/resume focussed that you might
as well just trojan the box until the next reboot as its likely to be a
couple of weeks a way.

Alan




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Eric Paris
2012-11-01 15:10:02 UTC
Permalink
Post by Alan Cox
Post by Eric Paris
Imagine you run windows and you've never heard of Linux.
To those people I think you mean "never heard of Ubuntu" ;-)
:-)
Post by Alan Cox
With all the current posted RH patches I can still take over
the box as root trivially enough and you seem to have so far abolished
suspend to disk, kexec and a pile of other useful stuff. To actually lock
it down you'll have to do a ton more of this.
I'm guessing those writing the patches would like to hear about these.
Suspend to disk and kexec can probably both be fixed up to work...
Post by Alan Cox
Actually from what I've seen on
the security front there seems to a distinct view that secure boot is
irrelevant because Windows 8 is so suspend/resume focussed that you might
as well just trojan the box until the next reboot as its likely to be a
couple of weeks a way.
Bit of a straw man isn't it? Hey, don't fix A, I can do B! I'm not
saying you're wrong, nor that maybe online attacks which don't persist
across reboot wouldn't be more likely, but they aren't attacking the
same problem. (I haven't heard any progress on what you point out,
but at least we have some progress on some small class of boot time
persistent attacks)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Pavel Machek
2012-11-01 20:30:03 UTC
Permalink
Hi!
Post by Eric Paris
Post by James Bottomley
But that doesn't really help me: untrusted root is an oxymoron.
Imagine you run windows and you've never heard of Linux. You like
that only windows kernels can boot on your box and not those mean
nasty hacked up malware kernels. Now some attacker manages to take
over your box because you clicked on that executable for young models
in skimpy bathing suits. That executable rewrote your bootloader to
launch a very small carefully crafted Linux environment. This
environment does nothing but launch a perfectly valid signed Linux
kernel, which gets a Windows environment all ready to launch after
resume and goes to sleep. Now you have to hit the power button twice
every time you turn on your computer, weird, but Windows comes up, and
secureboot is still on, so you must be safe!
Ok, so you cripple kexec / suspend to disallow this, and then...


...attacker launches carefuly crafter Linux environment, that just launches
X and fullscreen wine.

Sure, timing may be slightly different, but Windows came up and secureboot is still
on.. so user happily enters his bank account details.

Could someone write down exact requirements for Linux kernel to be signed by Microsoft?
Because thats apparently what you want, and I don't think crippling kexec/suspend is
enough.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Chris Friesen
2012-11-01 21:10:02 UTC
Permalink
Post by Pavel Machek
Could someone write down exact requirements for Linux kernel to be signed by Microsoft?
Because thats apparently what you want, and I don't think crippling kexec/suspend is
enough.
As I understand it, the kernel won't be signed by Microsoft.

Rather, the bootloader will be signed by Microsoft and the vendors will
be the ones that refuse to sign a kernel unless it is reasonably assured
that it won't be used as an attack vector.

If you want fully-open behaviour it's still possible, you just need to
turn off secure boot.

With secure boot enabled, then the kernel should refuse to let an
unsigned kexec load new images, and kexec itself should refuse to load
unsigned images. Also the kernel would need to sign its
"suspend-to-disk" images and refuse to resume unsigned images.

Presumably the signing key for the "suspend-to-disk" images would need
to be stored somewhere that is not accessable even by root. It's not
clear to me how we would do this, but maybe it's possible with hardware
support.

Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Vivek Goyal
2012-11-02 15:00:02 UTC
Permalink
Post by Eric Paris
On Thu, Nov 1, 2012 at 5:59 AM, James Bottomley
Post by James Bottomley
But that doesn't really help me: untrusted root is an oxymoron.
Imagine you run windows and you've never heard of Linux. You like
that only windows kernels can boot on your box and not those mean
nasty hacked up malware kernels. Now some attacker manages to take
over your box because you clicked on that executable for young models
in skimpy bathing suits. That executable rewrote your bootloader to
launch a very small carefully crafted Linux environment. This
Rewrote bootloader on disk so that it gets executed next time? It
will not run as signature will not match.

Thanks
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Oliver Neukum
2012-11-01 10:20:01 UTC
Permalink
Post by James Bottomley
Post by Oliver Neukum
Post by Chris Friesen
Post by Oliver Neukum
That would do it on my system.
Maybe in theory you could solve this by the kernel invalidating images
it hasn't written itself and forbidding to change the resume partition from the
kernel command line, but that would break user space hibernation.
If the resuming kernel refuses to resume from images it didn't create
itself, why do you need to forbid changing the resume partition from the
kernel command line?
You don't. Signed images solve the problem.
I really don't think they do. The proposed attack vector is to try to
prevent a local root exploit from running arbitrary in-kernel code,
because that would compromise the secure boot part of the kernel.
Well, it is an attempt to prevent unsigned code from altering signed
code or data structures private to signed code. That can be seen as
a technical question. What that is useful for is not strictly a technical
question.

We can of course discuss whether secure boot makes sense at all.
But that is a different discussion. Once it is decided that it is to be
implemented, some issues arise logically.
Post by James Bottomley
The point I'm making is that given that the majority of exploits will
already be able to execute arbitrary code in-kernel, there's not much
point trying to consider features like this as attacker prevention. We
should really be focusing on discussing why we'd want to prevent a
legitimate local root from writing to the suspend partition in a secure
boot environment.
That is strictly speaking what we are discussing.
First, it is not given that root is local.
Second, we don't want to stop root from writing to a partition.
We just want to prevent that from altering kernel memory.

Regards
Oliver

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Jiri Kosina
2012-10-31 17:30:02 UTC
Permalink
Post by Alan Cox
Post by Alan Cox
Post by Jiri Kosina
Prepare (as a root) a hand-crafted image, reboot, let the kernel resume
from that artificial image.
It's not signed. It won't reboot from that image.
The kernel is signed. The kernel doesn't check the signature on the
suspend image.
Which doesn't matter. How are you going to create the tampered image in
the first place ?
Editing the suspend partition/file directly when trusted kernel is booted.
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Matthew Garrett
2012-10-31 17:20:02 UTC
Permalink
Post by Alan Cox
On Wed, 31 Oct 2012 16:55:04 +0100 (CET)
Post by Jiri Kosina
Prepare (as a root) a hand-crafted image, reboot, let the kernel resume
from that artificial image.
It's not signed. It won't reboot from that image.
The kernel is signed. The kernel doesn't check the signature on the
suspend image.
--
Matthew Garrett | ***@srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Matthew Garrett
2012-10-31 16:00:02 UTC
Permalink
1) Gain root.
2) Modify swap partition directly.
3) Force reboot.
4) Win.

Root should not have the ability to elevate themselves to running
arbitrary kernel code. Therefore, the above attack needs to be
impossible.
--
Matthew Garrett | ***@srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Alan Cox
2012-10-31 17:10:01 UTC
Permalink
On Wed, 31 Oct 2012 15:56:35 +0000
Post by Matthew Garrett
1) Gain root.
2) Modify swap partition directly.
3) Force reboot.
4) Win.
Root should not have the ability to elevate themselves to running
arbitrary kernel code. Therefore, the above attack needs to be
impossible.
To protect swap you need to basically disallow any unencrypted swap (as
he OS can't prove any given swap device is local and inside the case) and
disallow the use of most disk management tools (so you'll need to write a
few new management interfaces or implement the BPF based command filters
that have been discussed for years).

In addition of course there is no requirement that a device returns
the data you put on it so subverted removable media is a potential issue.
Or indeed just cheap memory sticks that do it anyway ;)

Oh and of course the file systems in default mode don't guarantee this so
you'll need to fix ext3, ext4 8)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Shea Levy
2012-10-31 17:10:02 UTC
Permalink
Post by Alan Cox
On Wed, 31 Oct 2012 15:56:35 +0000
Post by Matthew Garrett
1) Gain root.
2) Modify swap partition directly.
3) Force reboot.
4) Win.
Root should not have the ability to elevate themselves to running
arbitrary kernel code. Therefore, the above attack needs to be
impossible.
To protect swap you need to basically disallow any unencrypted swap (as
he OS can't prove any given swap device is local and inside the case) and
disallow the use of most disk management tools (so you'll need to write a
few new management interfaces or implement the BPF based command filters
that have been discussed for years).
Can any kernel memory get swapped? If not all root can do is mess with
the memory of other userspace processes, which isn't a use-case that
secure boot cares about from my understanding.
Post by Alan Cox
In addition of course there is no requirement that a device returns
the data you put on it so subverted removable media is a potential issue.
Or indeed just cheap memory sticks that do it anyway ;)
Oh and of course the file systems in default mode don't guarantee this so
you'll need to fix ext3, ext4 8)
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Jiri Kosina
2012-10-31 16:10:01 UTC
Permalink
Post by Josh Boyer
I have a patch that disables that. I imagine it will be included in the
next submission of the patchset.
http://jwboyer.fedorapeople.org/pub/0001-hibernate-Disable-in-a-Secure-Boot-environment.patch
I don't see that patch touching kernel/power/user.c, so using 's2disk' to
suspend machine seems to be still possible even with this patch applied,
right?
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Josh Boyer
2012-10-31 16:20:02 UTC
Permalink
Post by Jiri Kosina
Post by Josh Boyer
I have a patch that disables that. I imagine it will be included in the
next submission of the patchset.
http://jwboyer.fedorapeople.org/pub/0001-hibernate-Disable-in-a-Secure-Boot-environment.patch
I don't see that patch touching kernel/power/user.c, so using 's2disk' to
suspend machine seems to be still possible even with this patch applied,
right?
Oh, yes. Good catch. I'll add similar checks there as well in the next
revision. Thanks!

josh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Matthew Garrett
2012-10-31 15:10:02 UTC
Permalink
Post by Jiri Kosina
Reading stored memory image (potentially tampered before reboot) from disk
is basically DMA-ing arbitrary data over the whole RAM. I am currently not
able to imagine a scenario how this could be made "secure" (without
storing private keys to sign the hibernation image on the machine itself
which, well, doesn't sound secure either).
shim generates a public and private key. It hands the kernel the private
key in a boot parameter and stores the public key in a boot variable. On
suspend, the kernel signs the suspend image with that private key and
discards it. On the next boot, shim generates a new key pair and hands
the new private key to the kernel along with the old public key. The
kernel verifies the suspend image before resuming it. The only way to
subvert this would be to be able to access kernel memory directly, which
means the attacker has already won.

Now someone just needs to write it.
--
Matthew Garrett | ***@srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Shea Levy
2012-10-31 15:10:02 UTC
Permalink
Post by Matthew Garrett
Post by Jiri Kosina
Reading stored memory image (potentially tampered before reboot) from disk
is basically DMA-ing arbitrary data over the whole RAM. I am currently not
able to imagine a scenario how this could be made "secure" (without
storing private keys to sign the hibernation image on the machine itself
which, well, doesn't sound secure either).
shim generates a public and private key. It hands the kernel the private
key in a boot parameter and stores the public key in a boot variable. On
suspend, the kernel signs the suspend image with that private key and
discards it. On the next boot, shim generates a new key pair and hands
the new private key to the kernel along with the old public key. The
kernel verifies the suspend image before resuming it. The only way to
subvert this would be to be able to access kernel memory
Or the boot variable where you stored the key, but in that case I'd say
the attacker has won too.
Post by Matthew Garrett
directly, which
means the attacker has already won.
Now someone just needs to write it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Matthew Garrett
2012-10-31 15:10:03 UTC
Permalink
Post by Shea Levy
Or the boot variable where you stored the key, but in that case I'd
say the attacker has won too.
Right, in that case they can compromise MOK.
--
Matthew Garrett | ***@srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Takashi Iwai
2012-10-31 17:30:02 UTC
Permalink
At Mon, 29 Oct 2012 17:41:31 +0000,
Post by Matthew Garrett
Post by Jiri Kosina
This is pretty much identical to the first patchset, but with the capability
renamed (CAP_COMPROMISE_KERNEL) and the kexec patch dropped. If anyone wants
to deploy these then they should disable kexec until support for signed
kexec payloads has been merged.
Apparently your patchset currently doesn't handle device firmware loading,
nor do you seem to mention in in the comments.
Correct.
Post by Jiri Kosina
I believe signed firmware loading should be put on plate as well, right?
I think that's definitely something that should be covered. I hadn't
worried about it immediately as any attack would be limited to machines
with a specific piece of hardware, and the attacker would need to expend
a significant amount of reverse engineering work on the firmware - and
we'd probably benefit from them doing that in the long run...
request_firmware() is used for microcode loading, too, so it's fairly
a core part to cover, I'm afraid.

I played a bit about this yesterday. The patch below is a proof of
concept to (ab)use the module signing mechanism for firmware loading
too. Sign firmware files via scripts/sign-file, and put to
/lib/firmware/signed directory.

It's just a rough cut, and the module options are other pieces there
should be polished better, of course. Also another signature string
should be better for firmware files :)


Takashi

---
diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index b34b5cd..2bc8415 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -145,6 +145,12 @@ config EXTRA_FIRMWARE_DIR
this option you can point it elsewhere, such as /lib/firmware/ or
some other directory containing the firmware files.

+config FIRMWARE_SIG
+ bool "Firmware signature check"
+ depends on FW_LOADER && MODULE_SIG
+ help
+ Check the embedded signature of firmware files like signed modules.
+
config DEBUG_DRIVER
bool "Driver Core verbose debug messages"
depends on DEBUG_KERNEL
diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 8945f4e..81fc8a4 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -268,6 +268,12 @@ static void fw_free_buf(struct firmware_buf *buf)

/* direct firmware loading support */
static const char *fw_path[] = {
+#ifdef CONFIG_FIRMWARE_SIG
+ "/lib/firmware/updates/" UTS_RELEASE "/signed",
+ "/lib/firmware/updates/signed",
+ "/lib/firmware/" UTS_RELEASE "/signed",
+ "/lib/firmware/signed",
+#endif
"/lib/firmware/updates/" UTS_RELEASE,
"/lib/firmware/updates",
"/lib/firmware/" UTS_RELEASE,
@@ -844,6 +850,41 @@ exit:
return fw_priv;
}

+#ifdef CONFIG_FIRMWARE_SIG
+/* XXX */
+extern int mod_verify_sig(const void *mod, unsigned long *_modlen);
+
+static bool sig_enforce;
+module_param(sig_enforce, bool, 0444);
+
+static int firmware_sig_check(struct firmware_buf *buf)
+{
+ unsigned long markerlen = sizeof(MODULE_SIG_STRING) - 1;
+ long len;
+ int err;
+
+ len = buf->size - markerlen;
+ if (len <= 0 ||
+ memcmp(buf->data + len, MODULE_SIG_STRING, markerlen)) {
+ pr_debug("%s: no signature found\n", buf->fw_id);
+ return sig_enforce ? -ENOKEY : 0;
+ }
+ err = mod_verify_sig(buf->data, &len);
+ if (err < 0) {
+ pr_debug("%s: signature error: %d\n", buf->fw_id, err);
+ return err;
+ }
+ buf->size = len;
+ pr_debug("%s: signature OK!\n", buf->fw_id);
+ return 0;
+}
+#else
+static inline int firmware_sig_check(struct firmware_buf *buf)
+{
+ return 0;
+}
+#endif
+
static int _request_firmware_load(struct firmware_priv *fw_priv, bool uevent,
long timeout)
{
@@ -909,6 +950,9 @@ handle_fw:
if (!buf->size || test_bit(FW_STATUS_ABORT, &buf->status))
retval = -ENOENT;

+ if (!retval)
+ retval = firmware_sig_check(buf);
+
/*
* add firmware name into devres list so that we can auto cache
* and uncache firmware for device.
diff --git a/kernel/module_signing.c b/kernel/module_signing.c
index ea1b1df..c39f49b 100644
--- a/kernel/module_signing.c
+++ b/kernel/module_signing.c
@@ -11,6 +11,7 @@

#include <linux/kernel.h>
#include <linux/err.h>
+#include <linux/export.h>
#include <crypto/public_key.h>
#include <crypto/hash.h>
#include <keys/asymmetric-type.h>
@@ -247,3 +248,4 @@ error_put_key:
pr_devel("<==%s() = %d\n", __func__, ret);
return ret;
}
+EXPORT_SYMBOL_GPL(mod_verify_sig);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Alan Cox
2012-10-31 17:40:02 UTC
Permalink
That does still leave me a little uneasy as far as the microcode
licenses go. I don't know that we can distribute signed copies of some
of them, and we obviously can't sign at the user end.
You seem to put them in signed rpm packages ?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Matthew Garrett
2012-10-31 17:50:02 UTC
Permalink
Post by Alan Cox
That does still leave me a little uneasy as far as the microcode
licenses go. I don't know that we can distribute signed copies of some
of them, and we obviously can't sign at the user end.
You seem to put them in signed rpm packages ?
That's not a modification of the files that say "You have permission to
distribute unmodified versions of this file". If a lawyer says this is
fine, I'm happy.
--
Matthew Garrett | ***@srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Matthew Garrett
2012-10-31 17:40:04 UTC
Permalink
Post by Takashi Iwai
request_firmware() is used for microcode loading, too, so it's fairly
a core part to cover, I'm afraid.
I played a bit about this yesterday. The patch below is a proof of
concept to (ab)use the module signing mechanism for firmware loading
too. Sign firmware files via scripts/sign-file, and put to
/lib/firmware/signed directory.
That does still leave me a little uneasy as far as the microcode
licenses go. I don't know that we can distribute signed copies of some
of them, and we obviously can't sign at the user end.
--
Matthew Garrett | ***@srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Takashi Iwai
2012-10-31 19:00:03 UTC
Permalink
At Wed, 31 Oct 2012 17:37:28 +0000,
Post by Takashi Iwai
request_firmware() is used for microcode loading, too, so it's fairly
a core part to cover, I'm afraid.
I played a bit about this yesterday. The patch below is a proof of
concept to (ab)use the module signing mechanism for firmware loading
too. Sign firmware files via scripts/sign-file, and put to
/lib/firmware/signed directory.
That does still leave me a little uneasy as far as the microcode
licenses go. I don't know that we can distribute signed copies of some
of them, and we obviously can't sign at the user end.
Yeah, that's a concern. Although this is a sort of "container" and
keeping the original data as is, it might be regarded as a
modification.

Another approach would be to a signature in a separate file, but I'm
not sure whether it makes sense.


Takashi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
joeyli
2012-11-01 04:40:02 UTC
Permalink
於 三,2012-10-31 於 19:53 +0100,Takashi Iwai 提到:
Post by Takashi Iwai
At Wed, 31 Oct 2012 17:37:28 +0000,
Post by Takashi Iwai
request_firmware() is used for microcode loading, too, so it's fairly
a core part to cover, I'm afraid.
I played a bit about this yesterday. The patch below is a proof of
concept to (ab)use the module signing mechanism for firmware loading
too. Sign firmware files via scripts/sign-file, and put to
/lib/firmware/signed directory.
That does still leave me a little uneasy as far as the microcode
licenses go. I don't know that we can distribute signed copies of some
of them, and we obviously can't sign at the user end.
Yeah, that's a concern. Although this is a sort of "container" and
keeping the original data as is, it might be regarded as a
modification.
Another approach would be to a signature in a separate file, but I'm
not sure whether it makes sense.
I think it make sense because the private key is still protected by
signer. Any hacker who modified firmware is still need use private key
to generate signature, but hacker's private key is impossible to match
with the public key that kernel used to verify firmware.

And, I afraid we have no choice that we need put the firmware signature
in a separate file. Contacting with those company's legal department
will be very time-consuming, and I am not sure all company will agree we
put the signature with firmware then distribute.


Thanks a lot!
Joey Lee

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Alan Cox
2012-11-01 13:20:01 UTC
Permalink
Post by joeyli
I think it make sense because the private key is still protected by
signer. Any hacker who modified firmware is still need use private key
to generate signature, but hacker's private key is impossible to match
with the public key that kernel used to verify firmware.
And, I afraid we have no choice that we need put the firmware signature
in a separate file. Contacting with those company's legal department
will be very time-consuming, and I am not sure all company will agree we
put the signature with firmware then distribute.
Then you'd better stop storing it on disk because your disk drive is FEC
encoding it and adding a CRC 8)

It does want checking with a lawyer but my understanding is that if you
have a file which is a package that contains the firmware and a signature
then there is not generally a problem, any more than putting it in an RPM
file - it's packaging/aggregation. This should be referred to the Linux
Foundation folks perhaps - no point designing something badly to work
around a non existant issue.

Also the interface needs to consider that a lot of device firmware is
already signed. Nobody notices because they don't ever try and do their
own thus many drivers don't need extra signatures in fact.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Loading...