UBUNTU: SAUCE: aufs: rwsem owner changed to atmoic_long_t in 5.3
Commit 94a9717b3c40 ("locking/rwsem: Make rwsem->owner an
atomic_long_t") in 5.3-rc1 changed rwsem->owner from a task
struct pointer to an atomic long. Update aufs accordingly.
Linn Crosetto [Wed, 20 Feb 2019 15:48:23 +0000 (16:48 +0100)]
UBUNTU: SAUCE: (efi-lockdown) arm64: add kernel config option to lock down when in Secure Boot mode
Add a kernel configuration option to lock down the kernel, to restrict
userspace's ability to modify the running kernel when UEFI Secure Boot is
enabled. Based on the x86 patch by Matthew Garrett.
Determine the state of Secure Boot in the EFI stub and pass this to the
kernel using the FDT.
Signed-off-by: Linn Crosetto <linn@hpe.com>
[bwh: Forward-ported to 4.10: adjust context]
[Lukas Wunner: Forward-ported to 4.11: drop parts applied upstream]
[bwh: Forward-ported to 4.15 and lockdown patch set:
- Pass result of efi_get_secureboot() in stub through to
efi_set_secure_boot() in main kernel
- Use lockdown API and naming]
[bwh: Forward-ported to 4.19.3: adjust context in update_fdt()]
[dannf: Moved init_lockdown() call after uefi_init(), fixing SB detection]
(from https://salsa.debian.org/kernel-team/linux/blob/4c4f3e03fdaaa674275c7197cae156e606dfaa4b/debian/patches/features/all/lockdown/arm64-add-kernel-config-option-to-lock-down-when.patch) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
"kexec_file: split KEXEC_VERIFY_SIG into KEXEC_SIG and
KEXEC_SIG_FORCE" missed several locations which used the old
option, and also missed the fact that arm64 also supports kexec
image signature verification. Finish the changes started in that
patch.
Fixes: "kexec_file: split KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE" Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Seth Forshee [Thu, 4 May 2017 13:09:04 +0000 (08:09 -0500)]
UBUNTU: SAUCE: (efi-lockdown) efi: Sanitize boot_params in efi stub
The efi stub will set the value of boot_params.secure_boot
without first checking whether boot_params has been sanitized. If
they have not, the value of secure_boot will be cleared later
when boot_params is sanitized. This currently happens with grub
as it currently does not clear the sentinel, and thus the kernel
cannot determine the secure boot state.
Since the efi stub is modifying a field in an area subject to
sanitization, it must first sanitize boot_params if needed. Later
sanitization by the decompressor will do nothing as the sentinel
value will have been cleared.
Robert Holmes [Tue, 23 Apr 2019 07:39:29 +0000 (07:39 +0000)]
UBUNTU: SAUCE: (efi-lockdown) KEYS: Make use of platform keyring for module signature verify
This patch completes commit 278311e417be ("kexec, KEYS: Make use of
platform keyring for signature verify") which, while adding the
platform keyring for bzImage verification, neglected to also add
this keyring for module verification.
As such, kernel modules signed with keys from the MokList variable
were not successfully verified.
Signed-off-by: Robert Holmes <robeholmes@gmail.com>
(cherry picked from commit 0beb1b712d4d8e2a3ca5dc4d7b6a018a55a5342e
git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
David Howells [Tue, 27 Feb 2018 10:04:55 +0000 (10:04 +0000)]
UBUNTU: SAUCE: (efi-lockdown) efi: Lock down the kernel if booted in secure boot mode
UEFI Secure Boot provides a mechanism for ensuring that the firmware will
only load signed bootloaders and kernels. Certain use cases may also
require that all kernel modules also be signed. Add a configuration option
that to lock down the kernel - which includes requiring validly signed
modules - if the kernel is secure-booted.
Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
cc: linux-efi@vger.kernel.org
(cherry picked from commit 55346ce033dd548bf74d489d6ddf2bfc702c7d40
git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
David Howells [Tue, 27 Feb 2018 10:04:55 +0000 (10:04 +0000)]
UBUNTU: SAUCE: (efi-lockdown) efi: Add an EFI_SECURE_BOOT flag to indicate secure boot mode
UEFI machines can be booted in Secure Boot mode. Add an EFI_SECURE_BOOT
flag that can be passed to efi_enabled() to find out whether secure boot is
enabled.
Move the switch-statement in x86's setup_arch() that inteprets the
secure_boot boot parameter to generic code and set the bit there.
Suggested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
cc: linux-efi@vger.kernel.org Signed-off-by: Jeremy Cline <jcline@redhat.com>
(cherry picked from commit 80cc4bec33ca9429c01082ef9ad51c9f2cbc3f23
git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Peter Jones [Mon, 2 Oct 2017 22:18:30 +0000 (18:18 -0400)]
UBUNTU: SAUCE: (efi-lockdown) Make get_cert_list() use efi_status_to_str() to print error messages.
Signed-off-by: Peter Jones <pjones@redhat.com>
(cherry picked from commit 6e56736bc779dab3c1d80fd27796520420aab987
git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Peter Jones [Mon, 2 Oct 2017 22:22:13 +0000 (18:22 -0400)]
UBUNTU: SAUCE: (efi-lockdown) Add efi_status_to_str() and rework efi_status_to_err().
This adds efi_status_to_str() for use when printing efi_status_t
messages, and reworks efi_status_to_err() so that the two use a common
list of errors.
Signed-off-by: Peter Jones <pjones@redhat.com>
(cherry picked from commit 2d698a1d7806399a4c032b1a4a8a789eb0d6a836
git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Peter Jones [Mon, 2 Oct 2017 22:25:29 +0000 (18:25 -0400)]
UBUNTU: SAUCE: (efi-lockdown) Make get_cert_list() not complain about cert lists that aren't present.
Signed-off-by: Peter Jones <pjones@redhat.com>
(cherry picked from commit 9141f57f44623aad2ee5dfa29a44c63bfe4102ad
git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Vasily Gorbik [Wed, 21 Nov 2018 12:05:10 +0000 (13:05 +0100)]
UBUNTU: SAUCE: (efi-lockdown) debugfs: avoid EPERM when no open file operation defined
With "debugfs: Restrict debugfs when the kernel is locked down"
return code "r" is unconditionally set to -EPERM, which stays like that
until function return if no "open" file operation defined, effectivelly
resulting in "Operation not permitted" for all such files despite kernel
lock down status or CONFIG_LOCK_DOWN_KERNEL being enabled.
In particular this breaks 2 debugfs files on s390:
/sys/kernel/debug/s390_hypfs/diag_304
/sys/kernel/debug/s390_hypfs/diag_204
To address that set EPERM return code only when debugfs_is_locked_down
returns true.
Fixes: 3fc322605158 ("debugfs: Restrict debugfs when the kernel is locked down") Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
(cherry picked from commit f53c8aa05a37fb1c7b10f0b8fd84d9e0ad980c8c
git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
UBUNTU: SAUCE: (efi-lockdown) Add a SysRq option to lift kernel lockdown
Make an option to provide a sysrq key that will lift the kernel lockdown,
thereby allowing the running kernel image to be accessed and modified.
On x86 this is triggered with SysRq+x, but this key may not be available on
all arches, so it is set by setting LOCKDOWN_LIFT_KEY in asm/setup.h.
Since this macro must be defined in an arch to be able to use this facility
for that arch, the Kconfig option is restricted to arches that support it.
Signed-off-by: Kyle McMartin <kyle@redhat.com> Signed-off-by: David Howells <dhowells@redhat.com>
cc: x86@kernel.org
(cherry picked from commit e99a8098e8012d51d4651a609179b2f403e6d2fd
git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Matthew Garrett [Tue, 12 Mar 2019 19:50:30 +0000 (12:50 -0700)]
UBUNTU: SAUCE: (efi-lockdown) kexec: Allow kexec_file() with appropriate IMA policy when locked down
Systems in lockdown mode should block the kexec of untrusted kernels.
For x86 and ARM we can ensure that a kernel is trustworthy by validating
a PE signature, but this isn't possible on other architectures. On those
platforms we can use IMA digital signatures instead. Add a function to
determine whether IMA has or will verify signatures for a given event type,
and if so permit kexec_file() even if the kernel is otherwise locked down.
This is restricted to cases where CONFIG_INTEGRITY_TRUSTED_KEYRING is set
in order to prevent an attacker from loading additional keys at runtime.
David Howells [Wed, 28 Feb 2018 14:43:03 +0000 (14:43 +0000)]
UBUNTU: SAUCE: (efi-lockdown) lockdown: Print current->comm in restriction messages
Print the content of current->comm in messages generated by lockdown to
indicate a restriction that was hit. This makes it a bit easier to find
out what caused the message.
The message now patterned something like:
Lockdown: <comm>: <what> is restricted; see man kernel_lockdown.7
Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Matthew Garrett <matthewgarrett@google.com>
(cherry picked from commit baf80953aa8cb1cf9fbc261e7592ac2f9281fbba
git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
David Howells [Mon, 18 Feb 2019 12:45:02 +0000 (12:45 +0000)]
UBUNTU: SAUCE: (efi-lockdown) debugfs: Restrict debugfs when the kernel is locked down
Disallow opening of debugfs files that might be used to muck around when
the kernel is locked down as various drivers give raw access to hardware
through debugfs. Given the effort of auditing all 2000 or so files and
manually fixing each one as necessary, I've chosen to apply a heuristic
instead. The following changes are made:
(1) chmod and chown are disallowed on debugfs objects (though the root dir
can be modified by mount and remount, but I'm not worried about that).
(2) When the kernel is locked down, only files with the following criteria
are permitted to be opened:
- The file must have mode 00444
- The file must not have ioctl methods
- The file must not have mmap
(3) When the kernel is locked down, files may only be opened for reading.
Normal device interaction should be done through configfs, sysfs or a
miscdev, not debugfs.
Note that this makes it unnecessary to specifically lock down show_dsts(),
show_devs() and show_call() in the asus-wmi driver.
I would actually prefer to lock down all files by default and have the
the files unlocked by the creator. This is tricky to manage correctly,
though, as there are 19 creation functions and ~1600 call sites (some of
them in loops scanning tables).
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Andy Shevchenko <andy.shevchenko@gmail.com>
cc: acpi4asus-user@lists.sourceforge.net
cc: platform-driver-x86@vger.kernel.org
cc: Matthew Garrett <mjg59@srcf.ucam.org>
cc: Thomas Gleixner <tglx@linutronix.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Matthew Garrett <matthewgarrett@google.com>
(cherry picked from commit 9a9439ed9619f31bb154952821a6ad3072414d03
git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
David Howells [Mon, 18 Feb 2019 12:45:02 +0000 (12:45 +0000)]
UBUNTU: SAUCE: (efi-lockdown) bpf: Restrict kernel image access functions when the kernel is locked down
There are some bpf functions can be used to read kernel memory:
bpf_probe_read, bpf_probe_write_user and bpf_trace_printk. These allow
private keys in kernel memory (e.g. the hibernation image signing key) to
be read by an eBPF program and kernel memory to be altered without
restriction.
Completely prohibit the use of BPF when the kernel is locked down.
Suggested-by: Alexei Starovoitov <alexei.starovoitov@gmail.com> Signed-off-by: David Howells <dhowells@redhat.com>
cc: netdev@vger.kernel.org
cc: Chun-Yi Lee <jlee@suse.com>
cc: Alexei Starovoitov <alexei.starovoitov@gmail.com> Cc: Daniel Borkmann <daniel@iogearbox.net> Signed-off-by: Matthew Garrett <matthewgarrett@google.com>
(cherry picked from commit 179926cf8ba00329494df6f45fc537ab9540d485
git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
David Howells [Mon, 18 Feb 2019 12:45:02 +0000 (12:45 +0000)]
UBUNTU: SAUCE: (efi-lockdown) Lock down kprobes
Disallow the creation of kprobes when the kernel is locked down by
preventing their registration. This prevents kprobes from being used to
access kernel memory, either to make modifications or to steal crypto data.
Reported-by: Alexei Starovoitov <alexei.starovoitov@gmail.com> Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Matthew Garrett <matthewgarrett@google.com> Cc: Naveen N. Rao <naveen.n.rao@linux.ibm.com> Cc: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com> Cc: davem@davemloft.net Cc: Masami Hiramatsu <mhiramat@kernel.org>
(cherry picked from commit 54f9245ac0c09112c81a54801aafae01fdb866bf
git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
David Howells [Mon, 18 Feb 2019 12:45:01 +0000 (12:45 +0000)]
UBUNTU: SAUCE: (efi-lockdown) Lock down module params that specify hardware parameters (eg. ioport)
Provided an annotation for module parameters that specify hardware
parameters (such as io ports, iomem addresses, irqs, dma channels, fixed
dma buffers and other types).
Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk> Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Matthew Garrett <matthewgarrett@google.com>
(cherry picked from commit 95f8983c4f29cca06b6b0816f8b115894883e525
git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
David Howells [Mon, 18 Feb 2019 12:45:00 +0000 (12:45 +0000)]
UBUNTU: SAUCE: (efi-lockdown) Lock down TIOCSSERIAL
Lock down TIOCSSERIAL as that can be used to change the ioport and irq
settings on a serial port. This only appears to be an issue for the serial
drivers that use the core serial code. All other drivers seem to either
ignore attempts to change port/irq or give an error.
Reported-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: David Howells <dhowells@redhat.com>
cc: Jiri Slaby <jslaby@suse.com> Cc: linux-serial@vger.kernel.org Signed-off-by: Matthew Garrett <matthewgarrett@google.com>
(cherry picked from commit 2c55c6b218596f35387d393e98a6aee61a8d3924
git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Linn Crosetto [Mon, 18 Feb 2019 12:45:00 +0000 (12:45 +0000)]
UBUNTU: SAUCE: (efi-lockdown) acpi: Disable APEI error injection if the kernel is locked down
ACPI provides an error injection mechanism, EINJ, for debugging and testing
the ACPI Platform Error Interface (APEI) and other RAS features. If
supported by the firmware, ACPI specification 5.0 and later provide for a
way to specify a physical memory address to which to inject the error.
Injecting errors through EINJ can produce errors which to the platform are
indistinguishable from real hardware errors. This can have undesirable
side-effects, such as causing the platform to mark hardware as needing
replacement.
While it does not provide a method to load unauthenticated privileged code,
the effect of these errors may persist across reboots and affect trust in
the underlying hardware, so disable error injection through EINJ if
the kernel is locked down.
Signed-off-by: Linn Crosetto <linn@hpe.com> Signed-off-by: David Howells <dhowells@redhat.com>
cc: linux-acpi@vger.kernel.org Signed-off-by: Matthew Garrett <matthewgarrett@google.com>
(cherry picked from commit 927e9ae3b060cc59c5ba3807bc1813132987efe2
git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Linn Crosetto [Mon, 18 Feb 2019 12:45:00 +0000 (12:45 +0000)]
UBUNTU: SAUCE: (efi-lockdown) acpi: Disable ACPI table override if the kernel is locked down
From the kernel documentation (initrd_table_override.txt):
If the ACPI_INITRD_TABLE_OVERRIDE compile option is true, it is possible
to override nearly any ACPI table provided by the BIOS with an
instrumented, modified one.
When securelevel is set, the kernel should disallow any unauthenticated
changes to kernel space. ACPI tables contain code invoked by the kernel,
so do not allow ACPI tables to be overridden if the kernel is locked down.
Signed-off-by: Linn Crosetto <linn@hpe.com> Signed-off-by: David Howells <dhowells@redhat.com>
cc: linux-acpi@vger.kernel.org Signed-off-by: Matthew Garrett <matthewgarrett@google.com>
(cherry picked from commit b74b5755481ca47342cd5c189324acd3c24617f9
git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Josh Boyer [Mon, 18 Feb 2019 12:44:59 +0000 (12:44 +0000)]
UBUNTU: SAUCE: (efi-lockdown) acpi: Ignore acpi_rsdp kernel param when the kernel has been locked down
This option allows userspace to pass the RSDP address to the kernel, which
makes it possible for a user to modify the workings of hardware . Reject
the option when the kernel is locked down.
Signed-off-by: Josh Boyer <jwboyer@redhat.com> Signed-off-by: David Howells <dhowells@redhat.com>
cc: Dave Young <dyoung@redhat.com>
cc: linux-acpi@vger.kernel.org Signed-off-by: Matthew Garrett <matthewgarrett@google.com>
(cherry picked from commit 9042ec0d455fc5d2d33e55ebab11a7ed6f8e53b1
git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Matthew Garrett [Mon, 18 Feb 2019 12:44:59 +0000 (12:44 +0000)]
UBUNTU: SAUCE: (efi-lockdown) ACPI: Limit access to custom_method when the kernel is locked down
custom_method effectively allows arbitrary access to system memory, making
it possible for an attacker to circumvent restrictions on module loading.
Disable it if the kernel is locked down.
Signed-off-by: Matthew Garrett <mjg59@srcf.ucam.org> Signed-off-by: David Howells <dhowells@redhat.com>
cc: linux-acpi@vger.kernel.org Signed-off-by: Matthew Garrett <matthewgarrett@google.com>
(cherry picked from commit e957c3c8a2931bdc152ec19956cc68eb4a381e87
git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Matthew Garrett [Mon, 18 Feb 2019 12:44:59 +0000 (12:44 +0000)]
UBUNTU: SAUCE: (efi-lockdown) x86/msr: Restrict MSR access when the kernel is locked down
Writing to MSRs should not be allowed if the kernel is locked down, since
it could lead to execution of arbitrary code in kernel mode. Based on a
patch by Kees Cook.
MSR accesses are logged for the purposes of building up a whitelist as per
Alan Cox's suggestion.
Signed-off-by: Matthew Garrett <mjg59@srcf.ucam.org> Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Kees Cook <keescook@chromium.org> Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
cc: x86@kernel.org Signed-off-by: Matthew Garrett <matthewgarrett@google.com>
(cherry picked from commit 683add52823d549d892a2ff4d977938867d3e6c9
git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Matthew Garrett [Mon, 18 Feb 2019 12:44:59 +0000 (12:44 +0000)]
UBUNTU: SAUCE: (efi-lockdown) x86: Lock down IO port access when the kernel is locked down
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.
This also implicitly locks down the KDADDIO, KDDELIO, KDENABIO and
KDDISABIO console ioctls.
Signed-off-by: Matthew Garrett <mjg59@srcf.ucam.org> Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
cc: x86@kernel.org Signed-off-by: Matthew Garrett <matthewgarrett@google.com>
(cherry picked from commit 893a1e17e5f77f86249afbc431fc62b69669e3d0
git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Matthew Garrett [Mon, 18 Feb 2019 12:44:59 +0000 (12:44 +0000)]
UBUNTU: SAUCE: (efi-lockdown) PCI: Lock down BAR access when the kernel is locked down
Any hardware that can potentially generate DMA has to be locked down in
order to avoid it being possible for an attacker to modify kernel code,
allowing them to circumvent disabled module loading or module signing.
Default to paranoid - in future we can potentially relax this for
sufficiently IOMMU-isolated devices.
Signed-off-by: Matthew Garrett <mjg59@srcf.ucam.org> Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
cc: linux-pci@vger.kernel.org Signed-off-by: Matthew Garrett <matthewgarrett@google.com>
(cherry picked from commit ee84290b96136e075f20536e6b468250173cf17c
git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Matthew Garrett [Mon, 18 Feb 2019 12:44:59 +0000 (12:44 +0000)]
UBUNTU: SAUCE: (efi-lockdown) uswsusp: Disable when the kernel is locked down
uswsusp allows a user process to dump and then restore kernel state, which
makes it possible to modify the running kernel. Disable this if the kernel
is locked down.
Signed-off-by: Matthew Garrett <mjg59@srcf.ucam.org> Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: James Morris <james.l.morris@oracle.com>
cc: linux-pm@vger.kernel.org Cc: pavel@ucw.cz Cc: rjw@rjwysocki.net Signed-off-by: Matthew Garrett <matthewgarrett@google.com>
(cherry picked from commit 1fda303f0b571217eec1a85d53fc92004f756a19
git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Josh Boyer [Mon, 18 Feb 2019 12:44:59 +0000 (12:44 +0000)]
UBUNTU: SAUCE: (efi-lockdown) hibernate: Disable when the kernel is locked down
There is currently no way to verify the resume image when returning
from hibernate. This might compromise the signed modules trust model,
so until we can work with signed hibernate images we disable it when the
kernel is locked down.
Signed-off-by: Josh Boyer <jwboyer@fedoraproject.org> Signed-off-by: David Howells <dhowells@redhat.com> Cc: rjw@rjwysocki.net Cc: pavel@ucw.cz
cc: linux-pm@vger.kernel.org Signed-off-by: Matthew Garrett <matthewgarrett@google.com>
(cherry picked from commit 97b9f22ab87edc9163138f13adfc3f9593d2cd8b
git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Jiri Bohac [Mon, 18 Feb 2019 12:44:58 +0000 (12:44 +0000)]
UBUNTU: SAUCE: (efi-lockdown) kexec_file: Restrict at runtime if the kernel is locked down
When KEXEC_SIG is not enabled, kernel should not load images through
kexec_file systemcall if the kernel is locked down.
[Modified by David Howells to fit with modifications to the previous patch
and to return -EPERM if the kernel is locked down for consistency with
other lockdowns. Modified by Matthew Garrett to remove the IMA
integration, which will be replaced by integrating with the IMA
architecture policy patches.]
Signed-off-by: Jiri Bohac <jbohac@suse.cz> Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: Jiri Bohac <jbohac@suse.cz>
cc: kexec@lists.infradead.org Signed-off-by: Matthew Garrett <matthewgarrett@google.com>
(cherry picked from commit 0534109a5184b15bdec4cb66822894478c689603
git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Jiri Bohac [Mon, 18 Feb 2019 12:44:58 +0000 (12:44 +0000)]
UBUNTU: SAUCE: (efi-lockdown) kexec_file: split KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE
This is a preparatory patch for kexec_file_load() lockdown. A locked down
kernel needs to prevent unsigned kernel images from being loaded with
kexec_file_load(). Currently, the only way to force the signature
verification is compiling with KEXEC_VERIFY_SIG. This prevents loading
usigned images even when the kernel is not locked down at runtime.
This patch splits KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE.
Analogous to the MODULE_SIG and MODULE_SIG_FORCE for modules, KEXEC_SIG
turns on the signature verification but allows unsigned images to be
loaded. KEXEC_SIG_FORCE disallows images without a valid signature.
[Modified by David Howells such that:
(1) verify_pefile_signature() differentiates between no-signature and
sig-didn't-match in its returned errors.
(2) kexec fails with EKEYREJECTED and logs an appropriate message if
signature checking is enforced and an signature is not found, uses
unsupported crypto or has no matching key.
(3) kexec fails with EKEYREJECTED if there is a signature for which we
have a key, but signature doesn't match - even if in non-forcing mode.
(4) kexec fails with EBADMSG or some other error if there is a signature
which cannot be parsed - even if in non-forcing mode.
(5) kexec fails with ELIBBAD if the PE file cannot be parsed to extract
the signature - even if in non-forcing mode.
]
Signed-off-by: Jiri Bohac <jbohac@suse.cz> Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: Jiri Bohac <jbohac@suse.cz>
cc: kexec@lists.infradead.org Signed-off-by: Matthew Garrett <matthewgarrett@google.com>
(cherry picked from commit 76f8617a4f9ddd1dae5cbd9c4efc509d43eb2503
git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Dave Young [Mon, 18 Feb 2019 12:44:58 +0000 (12:44 +0000)]
UBUNTU: SAUCE: (efi-lockdown) Copy secure_boot flag in boot params across kexec reboot
Kexec reboot in case secure boot being enabled does not keep the secure
boot mode in new kernel, so later one can load unsigned kernel via legacy
kexec_load. In this state, the system is missing the protections provided
by secure boot.
Adding a patch to fix this by retain the secure_boot flag in original
kernel.
secure_boot flag in boot_params is set in EFI stub, but kexec bypasses the
stub. Fixing this issue by copying secure_boot flag across kexec reboot.
Signed-off-by: Dave Young <dyoung@redhat.com> Signed-off-by: David Howells <dhowells@redhat.com>
cc: kexec@lists.infradead.org Signed-off-by: Matthew Garrett <matthewgarrett@google.com>
(cherry picked from commit b2c28f94329d925b643127e79203cdd75cf8f7f7
git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Matthew Garrett [Mon, 18 Feb 2019 12:44:58 +0000 (12:44 +0000)]
UBUNTU: SAUCE: (efi-lockdown) kexec_load: Disable at runtime if the kernel is locked down
The kexec_load() syscall permits the loading and execution of arbitrary
code in ring 0, which is something that lock-down is meant to prevent. It
makes sense to disable kexec_load() in this situation.
This does not affect kexec_file_load() syscall which can check for a
signature on the image to be booted.
Signed-off-by: Matthew Garrett <mjg59@srcf.ucam.org> Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Dave Young <dyoung@redhat.com>
cc: kexec@lists.infradead.org Signed-off-by: Matthew Garrett <matthewgarrett@google.com>
(cherry picked from commit 84b4c7089ba216902c63f5ab7a43690b99b78376
git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Matthew Garrett [Mon, 18 Feb 2019 12:44:58 +0000 (12:44 +0000)]
UBUNTU: SAUCE: (efi-lockdown) Restrict /dev/{mem,kmem,port} when the kernel is locked down
Allowing users to read and write to core kernel memory makes it possible
for the kernel to be subverted, avoiding module loading restrictions, and
also to steal cryptographic information.
Disallow /dev/mem and /dev/kmem from being opened this when the kernel has
been locked down to prevent this.
Also disallow /dev/port from being opened to prevent raw ioport access and
thus DMA from being used to accomplish the same thing.
Signed-off-by: Matthew Garrett <mjg59@srcf.ucam.org> Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Matthew Garrett <matthewgarrett@google.com> Cc: x86@kernel.org
(cherry picked from commit cd7e24db6a2d88ed9ce9b1813b0bf05966ce287f
git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
David Howells [Mon, 18 Feb 2019 12:44:58 +0000 (12:44 +0000)]
UBUNTU: SAUCE: (efi-lockdown) Enforce module signatures if the kernel is locked down
If the kernel is locked down, require that all modules have valid
signatures that we can verify.
I have adjusted the errors generated:
(1) If there's no signature (ENODATA) or we can't check it (ENOPKG,
ENOKEY), then:
(a) If signatures are enforced then EKEYREJECTED is returned.
(b) If there's no signature or we can't check it, but the kernel is
locked down then EPERM is returned (this is then consistent with
other lockdown cases).
(2) If the signature is unparseable (EBADMSG, EINVAL), the signature fails
the check (EKEYREJECTED) or a system error occurs (eg. ENOMEM), we
return the error we got.
Note that the X.509 code doesn't check for key expiry as the RTC might not
be valid or might not have been transferred to the kernel's clock yet.
[Modified by Matthew Garrett to remove the IMA integration. This will
be replaced with integration with the IMA architecture policy
patchset.]
Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: Jiri Bohac <jbohac@suse.cz> Signed-off-by: Matthew Garrett <matthewgarrett@google.com> Cc: Jessica Yu <jeyu@kernel.org>
(cherry picked from commit 4971e966a8c9f759b79790257eff086d5479101a
git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
David Howells [Mon, 18 Feb 2019 12:44:57 +0000 (12:44 +0000)]
UBUNTU: SAUCE: (efi-lockdown) Add the ability to lock down access to the running kernel image
Provide a single call to allow kernel code to determine whether the system
should be locked down, thereby disallowing various accesses that might
allow the running kernel image to be changed including the loading of
modules that aren't validly signed with a key we recognise, fiddling with
MSR registers and disallowing hibernation.
Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: James Morris <james.l.morris@oracle.com> Signed-off-by: Matthew Garrett <matthewgarrett@google.com>
(cherry picked from commit 1ea009a7a044928777fdabc4a6dedfe7ab16909e
git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
AceLan Kao [Wed, 17 Jul 2019 07:13:24 +0000 (15:13 +0800)]
UBUNTU: SAUCE: i2c: designware: add G3 3590 into i2c quirk
BugLink: https://bugs.launchpad.net/bugs/1836836
Add one missing platform which uses Goodix touchpad IC into i2c designware
quirk to prevent touchpad from entering runtime suspend.
Signed-off-by: AceLan Kao <acelan.kao@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Matthew Ruffell [Tue, 16 Jul 2019 01:09:56 +0000 (13:09 +1200)]
UBUNTU: SAUCE: Make CONFIG_DRM_HISI_HIBMC depend on ARM64
BugLink: https://bugs.launchpad.net/bugs/1762940
Hisilicon developed hibmc_drm for their arm64 based soc and did not
intend for this driver to be used on any other architecture than arm64.
Using it on amd64 leads to the screen being unreadable, forcing users to
manually blacklist the module on the kernel command line to use the d-i
server installer.
Make CONFIG_DRM_HISI_HIBMC firmly depend on arm64 to ensure it is not
built for other architectures.
Signed-off-by: Matthew Ruffell <matthew.ruffell@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
AceLan Kao [Thu, 11 Jul 2019 08:58:39 +0000 (16:58 +0800)]
UBUNTU: SAUCE: i2c: designware: add Inpiron 7591 into i2c quirk
BugLink: https://bugs.launchpad.net/bugs/1836020
Add one missing platform which uses Goodix touchpad IC into i2c designware
quirk to prevent touchpad from entering runtime suspend.
Signed-off-by: AceLan Kao <acelan.kao@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
This works around a possible stalled packet issue, which may occur due to
clock recovery from the PCH being too slow, when the LAN is transitioning
from K1 at 1G link speed.
AceLan Kao [Wed, 10 Jul 2019 09:04:35 +0000 (17:04 +0800)]
UBUNTU: SAUCE: i2c: designware: add Inpiron/Vostro 7590 into i2c quirk
BugLink: https://bugs.launchpad.net/bugs/1836020
Add 2 more platforms which uses Goodix touchpad IC into i2c designware
quirk to prevent touchpad from entering runtime suspend.
Signed-off-by: AceLan Kao <acelan.kao@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
UBUNTU: SAUCE: usbip: add -Wno-address-of-packed-member to EXTRA_CFLAGS
Fails to build with gcc 9.1.0 due to
-Werror=address-of-packed-member. One example:
usbip_network.c: In function 'usbip_net_pack_usb_device':
usbip_network.c:79:32: error: taking address of packed member of 'struct usbip_usb_device' may result in an unaligned pointer value [-Werror=address-of-packed-member]
79 | usbip_net_pack_uint32_t(pack, &udev->busnum);
| ^~~~~~~~~~~~~
All of these are code which is explicitly packing a struct, so
add -Wno-address-of-packed-member to EXTRA_CFLAGS to disable this
warning.
UBUNTU: SAUCE: usbip: ensure strings copied using strncpy are null-terminated
With gcc 9.1.0 the usbip build is failing:
In function 'strncpy',
inlined from 'read_usb_vudc_device' at usbip_device_driver.c:94:2:
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:10: error: '__builtin_strncpy' specified bound 256 equals destination size [-Werror=stringop-truncation]
It does appear that this could legitimately end up with a string
that is not null-terminated, and that the rest of the code is
expecting a null-terminated string. Fix this to ensure strings
will always be null-terminated.
UBUNTU: SAUCE: test_bpf: remove expected fail for Ctx heavy transformations test on s390
This test has started passing on s390, and because it is expected
to fail this is causing a test failure. I haven't tracked down
why it is now passing yet, but let's go ahead and remove the
expected fail for now to prevent showing failures in adt.
BugLink: https://bugs.launchpad.net/bugs/1833484
Dell machines come with goodix touchpad IC suffer from the double click
issue if the Designware I2C adapter enters runtime suspend.
It's because the goodix re-assert the interrupt if host doesn't read the
data within 100ms and desiginware takes a longer time to wake up from
runtime suspend. In the case, it got a second interrupt during
resuming, so it thinks it's a double click.
There is no simple way to fix this, it's a firmware issue and goodix
agrees to fix this in their firmware on next release, but this issue is
still affects the machines that don't come with an updated firmware. So,
add a quirk to mark those machines and avoid the designware to enter
runtime suspend.
Signed-off-by: AceLan Kao <acelan.kao@canonical.com> Acked-by: Timo Aaltonen <tjaalton@ubuntu.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Seth Forshee [Thu, 27 Jun 2019 18:11:33 +0000 (13:11 -0500)]
UBUNTU: SAUCE: selftests/powerpc: disable signal_fuzzer test
This test is causing an oops which results in a hange during ADT
testing. This is a new tests, and it crashes kernels in older
releases, therefore it is not a regression. Disable the test for
now so that ADT can run.
Kai-Heng Feng [Mon, 10 Jun 2019 07:21:41 +0000 (15:21 +0800)]
UBUNTU: SAUCE: USB: Disable USB2 LPM at shutdown
BugLink: https://bugs.launchpad.net/bugs/1757218
The QCA Rome USB Bluetooth controller has several issues once LPM gets
enabled:
- Fails to get enumerated in coldboot. [1]
- Drains more power (~ 0.2W) when the system is in S5. [2]
- Disappears after a warmboot. [2]
The issue happens because the device lingers at LPM L1 in S5, so device
can't get enumerated even after a reboot.
Seth Forshee [Thu, 30 May 2019 18:39:59 +0000 (13:39 -0500)]
UBUNTU: SAUCE: Revert "bpf, selftest: test global data/bss/rodata sections"
This reverts commit b915ebe6d9c8c6b5427e606c0ecee53df921382b,
which is failing to build. It seems the root cause is likely a
compiler issue (see [1] and [2]), but until the compiler is fixed
it means the net selftests can't run. Revert the new tests for
now.
Andy Whitcroft [Wed, 8 May 2019 13:24:40 +0000 (14:24 +0100)]
UBUNTU: SAUCE: tools -- fix add ability to disable libbfd
BugLink: https://bugs.launchpad.net/bugs/1826410
In commit 14541b1e7e ("perf build: Don't unconditionally link the libbfd
feature test to -liberty and -lz") the enablement code changed radically
neutering our override. Adapt to that new form.
Fixes: 546d50456e ("UBUNTU: SAUCE: tools -- add ability to disable libbfd") Signed-off-by: Andy Whitcroft <apw@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/1828092
We're seeing on the order of 10K cma_alloc() failure messages on
certain systems (HiSilicon D06 w/ SMMU BIOS-disabled, HP m400s).
While we continue to try and identify a solution that avoids
these messages altogether, in the meantime let's lessen the impact
(slow boot time, etc) by ratelimiting these messages. On a D06
w/ SMMU disabled, this drops the error messages count from 10758 to
21.
Signed-off-by: dann frazier <dann.frazier@canonical.com> Acked-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Andrea Righi [Sat, 20 Apr 2019 07:41:00 +0000 (09:41 +0200)]
UBUNTU: SAUCE: integrity: downgrade error to warning
BugLink: https://bugs.launchpad.net/bugs/1766201
In 58441dc86d7b the error "Unable to open file: ..." has been downgraded
to warning in the integrity/ima subsystem. Do the same for a similar
error message in the generic integrity subsystem.
Signed-off-by: Andrea Righi <andrea.righi@canonical.com> Acked-by: Connor Kuehl <connor.kuehl@canonical.com> Acked-by: Khalid Elmously <khalid.elmously@canonical.com> Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Currently, btrfs workloads employing shiftfs cause regression.
With btrfs unprivileged users can already toggle whether a subvolume
will be ro or rw. This is broken on current shiftfs as we haven't
whitelisted these ioctls().
To prevent such regression, we need to whitelist the ioctls
BTRFS_IOC_FS_INFO, BTRFS_IOC_SUBVOL_GETFLAGS, and
BTRFS_IOC_SUBVOL_SETFLAGS. All of them should be safe for unprivileged
users.
UBUNTU: SAUCE: shiftfs: lock down certain superblock flags
BugLink: https://bugs.launchpad.net/bugs/1827122
This locks down various superblock flags to prevent userns-root from
remounting a superblock with less restrictive options than the original
mark or underlay mount.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Before this commit we used to rely on an llseek method that was
targeted for regular files for both directories and regular files.
However, the realfile's f_pos was not correctly handled when userspace
called lseek(2) on a shiftfs directory file. Give directories their
own llseek operation so that seeking on a directory file is properly
supported.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com> Acked-by: Seth Forshee <seth.forshee@canonical.com> Acked-by: Tyler Hicks <tyhicks@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Before this commit we used to keep a reference to the shiftfs mark
mount's shiftfs_super_info which was stashed in the superblock of the
mark mount. The problem is that we only take a reference to the mount of
the underlay, i.e. the filesystem that is *under* the shiftfs mark
mount. This means when someone performs a shiftfs mark mount, then a
shiftfs overlay mount and then immediately unmounts the shiftfs mark
mount we muck with invalid memory since shiftfs_put_super might have
already been called freeing that memory.
Another solution would be to start reference counting. But this would be
overkill. We only care about the passthrough mount option of the mark
mount. And we only need it to verify that on remount the new passthrough
options of the shiftfs overlay are a subset of the mark mount's
passthrough options. In other scenarios we don't care. So copying up is
good enough and also only needs to happen once on mount, i.e. when a new
superblock is created and the .fill_super method is called.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com> Acked-by: Seth Forshee <seth.forshee@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
UBUNTU: SAUCE: shiftfs: fix passing of attrs to underaly for setattr
BugLink: https://bugs.launchpad.net/bugs/1824717
shiftfs_setattr() makes a copy of the attrs it was passed to pass
to the lower fs. It then calls setattr_prepare() with the original
attrs, and this may make changes which are not reflected in the
attrs passed to the lower fs. To fix this, copy the attrs to the
new struct for the lower fs after calling setattr_prepare().
Additionally, notify_change() may have set ATTR_MODE when one of
ATTR_KILL_S[UG]ID is set, and passing this combination to
notify_change() will trigger a BUG(). Do as overlayfs and
ecryptfs both do, and clear ATTR_MODE if either of those bits
is set.
UBUNTU: SAUCE: shiftfs: use translated ids when chaning lower fs attrs
BugLink: https://bugs.launchpad.net/bugs/1824350
shiftfs_setattr() is preparing a new set of attributes with the
owner translated for the lower fs, but it then passes the
original attrs. As a result the owner is set to the untranslated
owner, which causes the shiftfs inodes to also have incorrect
ids. For example:
# mkdir dir
# touch file
# ls -lh dir file
drwxr-xr-x 2 root root 4.0K Apr 11 13:05 dir
-rw-r--r-- 1 root root 0 Apr 11 13:05 file
# chown 500:500 dir file
# ls -lh dir file
drwxr-xr-x 2 10005001000500 4.0K Apr 11 12:42 dir
-rw-r--r-- 1 10005001000500 0 Apr 11 12:42 file
Fix this to pass the correct iattr struct to notify_change().
Reviewed-by: Christian Brauner <christian.brauner@ubuntu.com> Acked-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Acked-by: Tyler Hicks <tyhicks@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/1823186
Shiftfs currently only passes through a few ioctl()s to the underlay. These
are ioctl()s that are generally considered safe. Doing it for random
ioctl()s would be a security issue. Permissions for ioctl()s are not
checked before the filesystem gets involved so if we were to override
credentials we e.g. could do a btrfs tree search in the underlay which we
normally wouldn't be allowed to do.
However, the btrfs filesystem allows unprivileged users to perform various
operations through its ioctl() interface. With shiftfs these ioctl() are
currently not working. To not regress users that expect btrfs ioctl()s to
work in unprivileged containers we can create a whitelist of ioctl()s that
we allow to go through to the underlay and for which we also switch
credentials.
The main problem is how we switch credentials. Since permissions checks for
ioctl()s are
done by the actual file system and not by the vfs this would mean that any
additional capable(<cap>)-based checks done by the filesystem would
unconditonally pass after we switch credentials. So to make credential
switching safe we drop *all* capabilities when switching credentials. This
means that only inode-based permission checks will pass.
Btrfs also allows unprivileged users to delete snapshots when the
filesystem is mounted with user_subvol_rm_allowed mount option or if the
the callers is capable(CAP_SYS_ADMIN). The latter should never be the case
with unprivileged users. To make sure we only allow removal of snapshots in
the former case we drop all capabilities (see above) when switching
credentials.
Additonally, btrfs allows the creation of snapshots. To make this work we
need to be (too) clever. When doing snapshots btrfs requires that an fd to
the directory the snapshot is supposed to be created in be passed along.
This fd obviously references a shiftfs file and as such a shiftfs dentry
and inode. This will cause btrfs to yell EXDEV. To circumnavigate this
problem we need to silently temporarily replace the passed in fd with an fd
that refers to a file that references a btrfs dentry and inode.
BugLink: https://bugs.launchpad.net/bugs/1823186
/* Introduction */
The shiftfs filesystem is implemented as a stacking filesystem. Since it is
a stacking filesystem it shares concepts with overlayfs and ecryptfs.
Usually, shiftfs will be stacked upon another filesystem. The filesystem on
top - shiftfs - is referred to as "upper filesystem" or "overlay" and the
filesystem it is stacked upon is referred to as "lower filesystem" or
"underlay".
/* Marked and Unmarked shiftfs mounts */
To use shiftfs it is necessary that a given mount is marked as shiftable via
the "mark" mount option. Any mount of shiftfs without the "mark" mount option
not on top of a shiftfs mount with the "mark" mount option will be refused with
EPERM.
After a marked shiftfs mount has been performed other shiftfs mounts
referencing the marked shiftfs mount can be created. These secondary shiftfs
mounts are usually what are of interest.
The marked shiftfs mount will take a reference to the underlying mountpoint of
the directory it is marking as shiftable. Any unmarked shiftfts mounts
referencing this marked shifts mount will take a second reference to this
directory as well. This ensures that the underlying marked shiftfs mount can be
unmounted thereby dropping the reference to the underlying directory without
invalidating the mountpoint of said directory since the non-marked shiftfs
mount still holds another reference to it.
/* Stacking Depth */
Shiftfs tries to keep the stack as flat as possible to avoid hitting the
kernel enforced filesystem stacking limit.
/* Permission Model */
When the mark shiftfs mount is created shiftfs will record the credentials of
the creator of the super block and stash it in the super block. When other
non-mark shiftfs mounts are created that reference the mark shiftfs mount they
will stash another reference to the creators credentials. Before calling into
the underlying filesystem shiftfs will switch to the creators credentials and
revert to the original credentials after the underlying filesystem operation
returns.
/* Mount Options */
- mark
When set the mark mount option indicates that the mount in question is
allowed to be shifted. Since shiftfs it mountable in by user namespace root
non-initial user namespace this mount options ensures that the system
administrator has decided that the marked mount is safe to be shifted.
To mark a mount as shiftable CAP_SYS_ADMIN in the user namespace is required.
- passthrough={0,1,2,3}
This mount options functions as a bitmask. When set to a non-zero value
shiftfs will try to act as an invisible shim sitting on top of the
underlying filesystem.
- 1: Shifts will report the filesystem type of the underlay for stat-like
system calls.
- 2: Shiftfs will passthrough whitelisted ioctl() to the underlay.
- 3: Shiftfs will both use 1 and 2.
Note that mount options on a marked mount cannot be changed.
/* Extended Attributes */
Shiftfs will make sure to translate extended attributes.
/* Inodes Numbers */
Shiftfs inodes numbers are copied up from the underlying filesystem, i.e.
shiftfs inode numbers will be identical to the corresponding underlying
filesystem's inode numbers. This has the advantage that inotify and friends
should work out of the box.
(In essence, shiftfs is nothing but a 1:1 mirror of the underlying filesystem's
dentries and inodes.)
/* Device Support */
Shiftfs only supports the creation of pipe and socket devices. Character and
block devices cannot be created through shiftfs.
James Bottomley [Thu, 4 Apr 2019 13:39:11 +0000 (15:39 +0200)]
UBUNTU: SAUCE: shiftfs: uid/gid shifting bind mount
BugLink: https://bugs.launchpad.net/bugs/1823186
This allows any subtree to be uid/gid shifted and bound elsewhere. It
does this by operating simlarly to overlayfs. Its primary use is for
shifting the underlying uids of filesystems used to support
unpriviliged (uid shifted) containers. The usual use case here is
that the container is operating with an uid shifted unprivileged root
but sometimes needs to make use of or work with a filesystem image
that has root at real uid 0.
The mechanism is to allow any subordinate mount namespace to mount a
shiftfs filesystem (by marking it FS_USERNS_MOUNT) but only allowing
it to mount marked subtrees (using the -o mark option as root). Once
mounted, the subtree is mapped via the super block user namespace so
that the interior ids of the mounting user namespace are the ids
written to the filesystem.
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
[ saf: use designated initializers for path declarations to fix errors
with struct randomization ] Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
[update: port to 5.0] Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com> Acked-by: Tyler Hicks <tyhicks@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
John Johansen [Mon, 4 Feb 2019 13:23:14 +0000 (05:23 -0800)]
UBUNTU: SAUCE: apparmor: add proc subdir to attrs
This patch provides a /proc/<pid>/attr/apparmor/
subdirectory. Enabling userspace to use the apparmor attributes
without having to worry about collisions with selinux or smack on
interface files in /proc/<pid>/attr.
Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Casey Schaufler [Sat, 29 Dec 2018 01:35:55 +0000 (17:35 -0800)]
UBUNTU: SAUCE: LSM: Specify which LSM to display with /proc/self/attr/display
Create a new entry "display" in /proc/.../attr for controlling
which LSM security information is displayed for a process.
The name of an active LSM that supplies hooks for human readable
data may be written to "display" to set the value. The name of
the LSM currently in use can be read from "display".
Casey Schaufler [Wed, 12 Dec 2018 01:10:15 +0000 (17:10 -0800)]
UBUNTU: SAUCE: LSM: Limit calls to certain module hooks
LSM hooks dealing with security context strings should
only be called for one security module. Add call macros
that invoke a single module hook and us in for those cases.
John Johansen [Mon, 18 Mar 2019 23:11:45 +0000 (16:11 -0700)]
UBUNTU: SAUCE: LSM: Infrastructure management of the sock security
Move management of the sock->sk_security blob out
of the individual security modules and into the security
infrastructure. Instead of allocating the blobs from within
the modules the modules tell the infrastructure how much
space is required, and the space is allocated there.
Signed-off-by: Casey Schaufler <casey@schaufler-ca.com> Signed-off-by: John Johansen <john.johansen@canonical.com>
[ saf: resolve minor conflict in security/selinux/netlabel.c
when rebasing to 5.2-rc1 ] Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Seth Forshee [Wed, 27 Feb 2019 14:17:08 +0000 (08:17 -0600)]
UBUNTU: SAUCE: selftests: net: Don't fail test_vxlan_under_vrf on xfail
I changed the test for VXLAN underlay in non-default VRF to print
XFAIL for expected failure, but the script still exits with an
error which makes the test overall fail. Fix this to still exit
successfully following the xfail.
projects / mirror_ubuntu-eoan-kernel.git / log