On 2022-09-26 16:18:18, Jeff Moyer wrote:
> Tyler Hicks writes:
>
> > The alignment constraint for namespace creation in a region was
> > increased, from 2M to 16M, for non-PowerPC architectures in v5.7 with
> > commit 2522afb86a8c ("libnvdimm/region: Introduce an
On 2022-08-30 00:45:05, Tyler Hicks wrote:
> The alignment constraint for namespace creation in a region was
> increased, from 2M to 16M, for non-PowerPC architectures in v5.7 with
> commit 2522afb86a8c ("libnvdimm/region: Introduce an 'align'
> attribute"). The th
n those
regions, despite not being aligned to 16M.
Link:
https://lore.kernel.org/lkml/CA+CK2bDJ3hrWoE91L2wpAk+Yu0_=GtYw=4glddd7mxs321b...@mail.gmail.com
Fixes: 2522afb86a8c ("libnvdimm/region: Introduce an 'align' attribute")
Signed-off-by: Tyler Hicks
---
While testing wi
t affects the first kernel release
with eCryptfs. I've added the following Fixes tag:
Fixes: 237fead61998 ("[PATCH] ecryptfs: fs/Makefile and fs/Kconfig")
I've pushed it to the next branch of tyhicks/ecryptfs.git.
Tyler
> ---
> fs/ecryptfs/main.c | 6 ++
> 1 fi
eader and demote other
> abuses
> fs: ecryptfs: inode: Help out nearly-there header and demote
> non-conformant ones
> fs: ecryptfs: keystore: Fix some kernel-doc issues and demote
> non-conformant headers
I've applied the eCryptfs fixes to the next branch of
tyhicks/ecryptfs.git. Thanks for the clean-up!
Tyler
while
applying:
Fixes: 0216f7f79217 ("eCryptfs: replace encrypt, decrypt, and inode size write")
Tyler
> ---
> fs/ecryptfs/crypto.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/ecryptfs/crypto.c b/fs/ecryptfs/crypto.c
> index a48116aa
format, i.e. '/*', to prevent kernel-doc from parsing it.
>
> Signed-off-by: Aditya Srivastava
Hello Aditya - Thank you for this fix. In the time it took me to review
this patch, someone else submitted a series that fixed all W=1 warnings
under fs/ecryptfs/:
https:
member 'flags' not
> described in 'ecryptfs_mount'
> fs/ecryptfs/main.c:478: warning: expecting prototype for ecryptfs_get_sb().
> Prototype was for ecryptfs_mount() instead
> fs/ecryptfs/main.c:645: warning: Function parameter or member 'vptr' not
> de
name'
> fs/ecryptfs/crypto.c:1897: warning: Excess function parameter 'length'
> description in 'ecryptfs_encrypt_and_encode_filename'
> fs/ecryptfs/crypto.c:2006: warning: Function parameter or member 'sb' not
> described in 'ecryptfs_deco
eneric_config_write32()?
> >
> > That was my suggestion, but as Mark pointed out that doesn't work if
> > pci_generic_config_write32 is wrapped (which is 4 out of 8 cases).
> >
> > Also, 3 of the cases are only for the root bus (bridge). Are 32-bit
> > writes to a bridge going to cause problems? For xgene, interestingly,
> > with DT _write32 is needed, but for ACPI it is not (only _read32). I
> > think xgene is practically dead though a few people still have
> > systems, but likely xgene with DT is really dead. The ECAM case was
> > for QCom server which is also pretty much dead. SA1100 nano-engine is
> > really old and something only a few people have at most (Russell
> > King). So ignoring all those, we're left with just loongson and iproc.
> > Maybe just remove the warning?
>
> Sigh, removing it sounds like the best option.
Hi Bjorn - Was this lockdep issue fixed in a different way than removing
the use of printk? I'm mostly interested in reducing the RW1C warnings
as Mark suggested here:
https://lore.kernel.org/lkml/20200806041455.11070-1-mark.tomlin...@alliedtelesis.co.nz/
While thinking how best to rejuvenate that patch, I came across this
thread in the archives and it seems like the plan shifted to completely
removing this printk callsite to address the lockdep issue. However,
neither patch ended up in Linus' tree nor in the current PCI tree (I
only peeked in the next branch).
What's everyone's preference at this point?
Thanks!
Tyler
On 2021-03-30 16:32:10, Aneesh Kumar K.V wrote:
> Tyler Hicks writes:
>
> > The alignment constraint for namespace creation in a region was
> > increased, from 2M to 16M, for non-PowerPC architectures in v5.7 with
> > commit 2522afb86a8c ("libnvdimm/region: Intro
n those
regions, despite not being aligned to 16M.
Fixes: 2522afb86a8c ("libnvdimm/region: Introduce an 'align' attribute")
Signed-off-by: Tyler Hicks
---
drivers/nvdimm/region_devs.c | 33 ++---
1 file changed, 18 insertions(+), 15 deletio
ccident, but other platforms update this value properly.
> So, fix it in ARM64 version of elfcorehdr_read() as well.
>
Fixes: e62aaeac426a ("arm64: kdump: provide /proc/vmcore file")
Reviewed-by: Tyler Hicks
Tyler
> Signed-off-by: Pavel Tatashin
> ---
> arch/arm64
70.921642] CPU7: shutdown
> <6>[ 70.922650] psci: CPU7 killed (polled 0 ms)
>
> Signed-off-by: Pavel Tatashin
> Reviewed-by: Kees Cook
> Reviewed-by: Petr Mladek
> Reviewed-by: Bhupesh Sharma
Reviewed-by: Tyler Hicks
Tyler
> Acked-by: Baoquan He
> -
igned-off-by: Allen Pais
Reviewed-by: Tyler Hicks
Tyler
> ---
> drivers/firmware/broadcom/tee_bnxt_fw.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/firmware/broadcom/tee_bnxt_fw.c
> b/drivers/firmware/broadcom/tee_bnxt_fw.c
> index ed10da5313e8.
e_remove(struct platform_device *pdev)
> return 0;
> }
>
> +/* optee_shutdown - Device Removal Routine
> + * @pdev: platform device information struct
> + *
> + * platform_shutdown is called by the platform subsystem to alter
oot time.
I cannot explain why '5.10.19 + these fixes' shows improvements over
5.4.88 for two of the three services but I suspect it is due to systemd
taking different code paths, units executing at different times,
unrelated kernel performance improvements, etc.
For all three patches,
Te
On 2021-02-25 17:38:25, Ondrej Mosnacek wrote:
> On Wed, Feb 24, 2021 at 3:43 PM Tyler Hicks
> wrote:
> > On 2021-02-24 10:33:46, Ondrej Mosnacek wrote:
> > > On Tue, Feb 23, 2021 at 11:37 PM Tyler Hicks
> > > wrote:
> > > > On 2021-02-23 15:50:56, Tyl
On 2021-02-24 10:33:46, Ondrej Mosnacek wrote:
> On Tue, Feb 23, 2021 at 11:37 PM Tyler Hicks
> wrote:
> > On 2021-02-23 15:50:56, Tyler Hicks wrote:
> > > On 2021-02-23 15:43:48, Tyler Hicks wrote:
> > > > I'm seeing a race during policy load while the
On 2021-02-23 15:50:56, Tyler Hicks wrote:
> On 2021-02-23 15:43:48, Tyler Hicks wrote:
> > I'm seeing a race during policy load while the "regular" sidtab
> > conversion is happening and a live conversion starts to take place in
> > sidtab_context_to_sid()
On 2021-02-23 15:43:48, Tyler Hicks wrote:
> I'm seeing a race during policy load while the "regular" sidtab
> conversion is happening and a live conversion starts to take place in
> sidtab_context_to_sid().
>
> We have an initial policy that's loaded by systemd
ed ("selinux: overhaul
sidtab to fix bug and improve performance"), that there's no need to
freeze the sidtab during policy reloads so I know that there's thought
given to these code paths running in parallel.
Can someone more knowledgeable on how the sidtab locking is expected to
work suggest a fix for this crash?
Tyler
-by: Pavel Tatashin
> Fixes: 58284a901b42 ("arm64/mm: Validate hotplug range before creating linear
> mapping")
Tested-by: Tyler Hicks
This fixes a memory hot plugging bug that I was seeing on 5.10, with the
introduction of 58284a901b42.
One comment below...
> ---
>
On 2021-02-05 12:01:55, Tyler Hicks wrote:
> On 2020-10-30 09:00:35, Mark Salyzyn wrote:
> > On 10/30/20 8:07 AM, Miklos Szeredi wrote:
> > > On Wed, Oct 21, 2020 at 5:19 PM Mark Salyzyn wrote:
> > > > Because of the overlayfs getxattr recursion, the incoming ino
ets up Overlayfs mounts, then that process
starts a service confined by another security context, then that service
may execute binaries that run under a third security context. In this
case, I'm talking about SELinux security contexts but it could be
AppArmor or anything else that you use to
it.kernel.org/pub/scm/linux/kernel/git/tyhicks/ecryptfs.git/log/?h=next
Thanks for the cleanup!
Tyler
> ---
> fs/ecryptfs/crypto.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/fs/ecryptfs/crypto.c b/fs/ecryptfs/crypto.c
> index 0681540c48d9..be90
missing
the trailing semicolon and then made Joe's suggested change before
pushing the patch to the eCryptfs next branch:
https://git.kernel.org/pub/scm/linux/kernel/git/tyhicks/ecryptfs.git/log/?h=next
Thanks for the cleanup!
Tyler
irect manipulation to the
lower filesystem.
Is the condition that you're trying to fix a result of going through the
this code path?
ecryptfs_unlink() -> ecryptfs_do_unlink() -> vfs_unlink() -> nfs_unlink() ->
nfs_sillyrename() -> nfs_async_unlink()
Tyler
> ---
>
Hi Linus,
The following changes since commit 83d09ad4b950651a95d37697f1493c00d888d0db:
Merge tag 'for-linus' of git://github.com/openrisc/linux (2021-01-21 18:35:02
-0800)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/tyhicks/ecryptfs.git
tags/ecr
int rc;
> +
> + for (entry = kimage->head; !(entry & IND_DONE); entry = *ptr++) {
> + addr = entry & PAGE_MASK;
> +
> + switch (entry & IND_FLAGS) {
> + case IND_DESTINATION:
> + dest = addr;
> +
On 2021-01-25 14:25:38, Miklos Szeredi wrote:
> On Fri, Jan 22, 2021 at 7:31 PM Tyler Hicks wrote:
> >
> > On 2021-01-19 17:22:03, Miklos Szeredi wrote:
> > > Prior to commit 7c03e2cda4a5 ("vfs: move cap_convert_nscap() call into
> > > vfs_setxattr()"
a file inside of an eCryptfs mount to verify that the bug exists after
7c03e2cda4a5 and then again to verify that this patch fixes the bug?
Tyler
>
> Restore old the behavior for ecryptfs that existed before the overlayfs
> fix. This does not fix ecryptfs's handling of complex use
es. Code that is enabled with CONFIG_FILE_LOCKING. So unless
> > I am missing something this introduces a different regression into
> > ecryptfs.
>
> This is in line with all the other cases of ecryptfs passing NULL as
> delegated inode.
>
> I'll defer this to the
function.
>
> Signed-off-by: Lakshmi Ramasubramanian
> Suggested-by: Tyler Hicks
> Fixes: 7b8589cc29e7 ("ima: on soft reboot, save the measurement list")
Reviewed-by: Tyler Hicks
Tyler
> ---
> include/linux/kexec.h | 5 +
> kernel/kexec_file.c
resulting in memory leak.
>
> Free the memory allocated for the IMA measurement list in
> the error code paths in ima_add_kexec_buffer() function.
>
> Signed-off-by: Lakshmi Ramasubramanian
> Suggested-by: Tyler Hicks
> Fixes: 7b8589cc29e7 ("ima: on soft reboot, sa
urements | tail -1 |
> > cut -d' ' -f 6
> >
> > Note that the actual verification of SELinux policy would require loading
> > the expected policy into an identical kernel on a pristine/known-safe
> > system and run the sha256sum /sys/kernel/selinux/policy there
On 2020-12-14 10:42:24, Tyler Hicks wrote:
> On 2020-12-11 06:01:54, Mimi Zohar wrote:
> > On Thu, 2020-12-10 at 21:10 -0600, Tyler Hicks wrote:
> > > On 2020-11-29 08:17:38, Mimi Zohar wrote:
> > > > Hi Sasha,
> > > >
> > > > On Wed, 2020-07-
On 2020-12-11 06:01:54, Mimi Zohar wrote:
> On Thu, 2020-12-10 at 21:10 -0600, Tyler Hicks wrote:
> > On 2020-11-29 08:17:38, Mimi Zohar wrote:
> > > Hi Sasha,
> > >
> > > On Wed, 2020-07-08 at 21:27 -0400, Sasha Levin wrote:
> > > > On Wed, Ju
unc CRITICAL_DATA, the data from all the
> supported kernel subsystems is measured.
>
> Signed-off-by: Tushar Sugandhi
Reviewed-by: Tyler Hicks
Tyler
> ---
> Documentation/ABI/testing/ima_policy | 2 ++
> security/integrity/ima/ima_policy.c | 37 +
Tushar Sugandhi
This looks nice. Thanks for the changes!
Reviewed-by: Tyler Hicks
Tyler
> ---
> Documentation/ABI/testing/ima_policy | 2 +-
> security/integrity/ima/ima_policy.c | 29
> 2 files changed, 26 insertions(+), 5 deletions(-)
>
> dif
On 2020-12-11 17:17:22, Tushar Sugandhi wrote:
>
>
> On 2020-12-11 4:25 p.m., Tyler Hicks wrote:
> > On 2020-12-11 15:58:03, Tushar Sugandhi wrote:
> > > A new IMA policy rule is needed for the IMA hook
> > > ima_measure_critical_data() and the cor
gt; Note that the actual verification of SELinux policy would require loading
> the expected policy into an identical kernel on a pristine/known-safe
> system and run the sha256sum /sys/kernel/selinux/policy there to get
> the expected hash.
>
> Signed-off-by: Lakshmi Ramasubra
t = rule->data_source;
> + break;
I guess this case should unconditionally return true in this patch and
then the include this additional logic in the next patch.
Sorry, I missed these on my last review.
Tyler
> default:
> return false;
> }
&
l
> integrity critical data.
>
> Signed-off-by: Tushar Sugandhi
Reviewed-by: Tyler Hicks
Tyler
> ---
> include/linux/ima.h | 6 ++
> security/integrity/ima/ima.h | 1 +
> security/integrity/ima/ima_api.c | 2 +-
> security/integrity/ima/i
er to extend them without code duplication.
>
> Refactor the keyring specific measurement constructs to be generic and
> reusable in other measurement scenarios.
>
> Signed-off-by: Tushar Sugandhi
> Reviewed-by: Tyler Hicks
This looks good to me. Thanks!
Tyler
> --
a buffer, which would be much smaller, instead of the buffer
> itself.
>
> Signed-off-by: Tushar Sugandhi
Reviewed-by: Tyler Hicks
Tyler
> ---
> security/integrity/ima/ima.h | 3 +-
> security/integrity/ima/ima_appraise.c| 2 +-
> securit
On 2020-12-11 09:36:30, Tyler Hicks wrote:
> The calls to pr_err() in this aren't quite following the style of the
> other error SELinux error messages.
Sorry, I left out a word. I meant to say that the calls to pr_err() in
this *file* aren't quite following the right style. Plea
Runtime disable is
deprecated, use selinux=0 on the kernel cmdline.\n");
security/selinux/selinuxfs.c: pr_err("SELinux: failed to load policy
booleans\n");
security/selinux/selinuxfs.c: pr_err("SELinux: failed to load policy
classes\n");
...
secu
2] should always
> include PCRs 8 & 9.
I'm still not clear on how an attestation server would know to include
PCRs 8 and 9 after this change came through a stable kernel update. It
doesn't seem like something appropriate for stable since it requires
code changes to attestation servers
On 2020-12-10 17:21:19, Tushar Sugandhi wrote:
>
>
> On 2020-12-10 2:38 p.m., Tyler Hicks wrote:
> > On 2020-12-09 11:42:06, Tushar Sugandhi wrote:
> > > The original IMA buffer data measurement sizes were small (e.g. boot
> > > command line), but the new buffe
e kernel command line
> contains "ima_policy=critical_data".
>
> Update the documentation on kernel parameters to document
> the new critical data builtin policy.
>
> Signed-off-by: Lakshmi Ramasubramanian
Reviewed-by: Tyler Hicks
Tyler
> ---
> Documentation/a
xtend the IMA hook ima_measure_critical_data() to support passing
> the data source label as an input parameter, so that the policy rule can
> be used to limit the measurements based on the label.
>
> Signed-off-by: Tushar Sugandhi
Reviewed-by: Tyler Hicks
Tyler
> ---
> in
unc CRITICAL_DATA, the data from all the
> supported kernel subsystems is measured.
>
> Signed-off-by: Tushar Sugandhi
This patch will look good once all the IMA_DATA_SOURCE stuff is moved
over from patch #4.
Tyler
> ---
> Documentation/ABI/testing/ima_policy | 2 ++
> security
try->action & ~(MEASURE | DONT_MEASURE))
> + return false;
> +
> + if (!(entry->flags & IMA_DATA_SOURCE) ||
> + (entry->flags & ~(IMA_FUNC | IMA_UID | IMA_PCR |
> + IMA_DATA_SOURCE)))
IMA_DATA_SOURCE shouldn't exist in this patch. This isn't the right
indentation, either. See how IMA_KEYRINGS is indented in the KEY_CHECK
case above.
Tyler
> + return false;
> +
> + if (ima_rule_contains_lsm_cond(entry))
> + return false;
> +
> break;
> default:
> return false;
> --
> 2.17.1
>
static int ima_parse_rule(char *rule, struct
> ima_rule_entry *entry)
> else if (IS_ENABLED(CONFIG_IMA_MEASURE_ASYMMETRIC_KEYS)
> &&
>strcmp(args[0].from, "KEY_CHECK") == 0)
> entry->func = KEY_CHECK;
> + else if (strcmp(args[0].from, "CRITICAL_DATA") == 0)
> + entry->func = CRITICAL_DATA;
> else
> result = -EINVAL;
> if (!result)
This hunk and the above change to Documentation/ABI/testing/ima_policy
need to be moved to the next patch when you introduce the policy
changes.
Tyler
> --
> 2.17.1
>
rent patch is fine:
Reviewed-by: Tyler Hicks
> ---
> security/integrity/ima/ima.h| 6 ++--
> security/integrity/ima/ima_api.c| 6 ++--
> security/integrity/ima/ima_main.c | 6 ++--
> security/integrity/ima/ima_policy.c | 49 ++---
>
e(&event_data, &entry, template);
> if (ret < 0) {
> audit_cause = "alloc_entry";
A few more lines below, not present in this context, is a call to
ima_store_template() with buf as the fourth parameter passed in. That
parameter eventually makes i
be changed to this:
Fixes: 32927393dc1c ("sysctl: pass kernel pointers to ->proc_handler")
If you agree, please adjust and resubmit with:
Reviewed-by: Tyler Hicks
Thank you!
Tyler
> Signed-off-by: Jann Horn
> ---
> kernel/seccomp.c | 4 ++--
> 1 file changed, 2 i
On 2020-11-05 09:28:38, Tyler Hicks wrote:
> On 2020-11-05 09:58:54, Will Deacon wrote:
> > On Wed, Nov 04, 2020 at 11:40:09PM -0600, Tyler Hicks wrote:
> > > On 2020-11-04 12:08:12, Will Deacon wrote:
> > > > On Tue, Nov 03, 2020 at 09:59:52AM -0600, Tyler Hicks wro
On 2020-11-05 09:58:54, Will Deacon wrote:
> On Wed, Nov 04, 2020 at 11:40:09PM -0600, Tyler Hicks wrote:
> > On 2020-11-04 12:08:12, Will Deacon wrote:
> > > On Tue, Nov 03, 2020 at 09:59:52AM -0600, Tyler Hicks wrote:
> > > > On 2020-09-21 14:15:55, Tyler Hick
On 2020-11-04 12:08:12, Will Deacon wrote:
> On Tue, Nov 03, 2020 at 09:59:52AM -0600, Tyler Hicks wrote:
> > On 2020-09-21 14:15:55, Tyler Hicks wrote:
> > > Provide the CONFIG_CMDLINE_EXTEND config option for arm64 kernels. This
> > > config option can be used to ext
On 2020-09-21 14:15:55, Tyler Hicks wrote:
> Provide the CONFIG_CMDLINE_EXTEND config option for arm64 kernels. This
> config option can be used to extend the kernel command line parameters,
> specified by the bootloader, with additional command line parameters
> specified i
/linux-integrity/e1fdcccb-ca51-4aee-ac83-9cde995ea...@canonical.com/
Reported-by: Kai-Heng Feng
Reported-by: Kenneth R. Crudup
Reported-by: Mimi Zohar
Cc: Thiébaud Weksteen
Cc: Ard Biesheuvel
Signed-off-by: Tyler Hicks
---
drivers/char/tpm/eventlog/efi.c | 5 +
1 file changed, 5 insertions
On 2020-10-28 10:41:02, Tyler Hicks wrote:
> Mimic the pre-existing ACPI and Device Tree event log behavior by not
> creating the binary_bios_measurements file when the EFI TPM event log is
> empty.
>
> This fixes the following NULL pointer dereference that can occur when
> r
On 2020-10-28 11:30:11, Tyler Hicks wrote:
> So, we need help from Kai, Kenneth, or Mimi to verify my assumption that
> their firmware is providing an empty main event log and a populated
> final event log.
Hi Kai, Kenneth, and Mimi - could one or two of you please follow these
steps:
On 2020-10-26 13:49:59, Kai-Heng Feng wrote:
>
>
> > On Oct 21, 2020, at 13:48, Tyler Hicks wrote:
> >
> > On 2020-10-20 17:07:50, Mimi Zohar wrote:
> >> On Tue, 2020-09-29 at 13:52 -0400, Mimi Zohar wrote:
> >>> On Mon, 2020-09-28 at 22:16
gt; >
> > I'm seeing this too on my test Ubuntu laptop. Reverting the patch
> > fixes it, but there's no data.
>
> For a while I wasn't able to boot the test system with secure boot
> enabled. The NULL pointer dereference problem occurred during the
W, we've had this patch applied to our internal kernel for a month
and haven't seen any issues.
Tyler
>
> > Thanks!
> >
> > Kai-Heng
>
> /Jarkko
>
strings without
having to concatenate the strings in early init.
Signed-off-by: Tyler Hicks
---
arch/arm64/kernel/kaslr.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/kernel/kaslr.c b/arch/arm64/kernel/kaslr.c
index b181e0544b79..4c779a67c2a6 10064
development kernel versions, where one
of the versions benefits from additional command line parameters,
such as debugging options.
2) Specifying additional command line parameters, for additional tuning
or debugging, when the bootloader does not offer an interactive mode.
Signed-off-by: Tyler
ASLR are enabled
* Set CONFIG_CMDLINE="nokaslr apparmor=0" and CONFIG_CMDLINE_FORCE=y
- The CONFIG_CMDLINE value is used and does not contain the
bootloader's command line
- AppArmor and KASLR are disabled
Tyler
Tyler Hicks (2):
arm64: kaslr: Refactor early init command line
On 2020-08-24 14:44:55, Mimi Zohar wrote:
> Hi Tyler,
>
> On Tue, 2020-08-11 at 14:26 -0500, Tyler Hicks wrote:
> > v2:
> > - Always return an ERR_PTR from ima_alloc_rule_opt_list() (Nayna)
> > - Add Lakshmi's Reviewed-by to both patches
> > - Rebased on c
authors don't assume that
these policy language constructs are supported.
Fixes: 2b60c0ecedf8 ("IMA: Read keyrings= option from the IMA policy")
Fixes: 5808611cccb2 ("IMA: Add KEY_CHECK func to measure keys")
Suggested-by: Nayna Jain
Signed-off-by: Tyler Hicks
Review
to be fully
parsed at this time) and using "|" as an alternation delimiter is
becoming the norm in IMA policy.
This series is based on commit 311aa6aafea4 ("ima: move
APPRAISE_BOOTPARAM dependency on ARCH_POLICY to runtime") in
next-integrity.
Tyler
Tyler Hicks (2):
ima:
f keyrings was longer than what could
fit in the fixed size tbuf buffer in ima_policy_show().
Fixes: 5c7bac9fb2c5 ("IMA: pre-allocate buffer to hold keyrings string")
Fixes: 2b60c0ecedf8 ("IMA: Read keyrings= option from the IMA policy")
Signed-off-by: Tyler Hicks
Reviewed-by:
On 2020-08-06 11:34:43, Nayna wrote:
>
> On 7/27/20 10:08 AM, Tyler Hicks wrote:
> > The ima_keyrings buffer was used as a work buffer for strsep()-based
> > parsing of the "keyrings=" option of an IMA policy rule. This parsing
> > was re-performed each tim
On 2020-08-05 09:07:48, Lakshmi Ramasubramanian wrote:
> On 8/5/20 8:45 AM, Tyler Hicks wrote:
> > On 2020-08-05 08:36:40, Casey Schaufler wrote:
> > > On 8/4/2020 6:14 PM, Lakshmi Ramasubramanian wrote:
> > > > On 8/4/20 6:04 PM, Casey Schaufler wrote:
> >
On 2020-08-05 09:21:24, Lakshmi Ramasubramanian wrote:
> On 8/5/20 9:14 AM, Tyler Hicks wrote:
> > On 2020-08-05 09:07:48, Lakshmi Ramasubramanian wrote:
> > > On 8/5/20 8:45 AM, Tyler Hicks wrote:
> > > > On 2020-08-05 08:36:40, Casey Schaufler wrote:
> >
gt; Ok, measuring the policy separately from other critical data makes
> > sense. Instead of measuring the policy, which is large, measure the
> > policy hash.
>
> I think that was the original approach. However, I had concerns with
> adding code to SELinux to compute a hash over the policy versus
> leaving that to IMA's existing policy and mechanism. If that's
> preferred I guess we can do it that way but seems less flexible and
> duplicative.
In AppArmor, we store the sha1 of the raw policy as the policy is
loaded. The hash is exposed to userspace in apparmorfs. See commit
5ac8c355ae00 ("apparmor: allow introspecting the loaded policy pre
internal transform").
It has proved useful as a mechanism for debugging as sometimes the
on-disk policy doesn't match the loaded policy and this can be a good
way to check that while providing support to users. John also mentions
checkpoint/restore in the commit message and I could certainly see how
the policy hashes would be useful in that scenario.
When thinking through how Lakshmi's series could be extended for
AppArmor support, I was thinking that the AppArmor policy measurement
would be a measurement of these hashes that we already have in place.
Perhaps there's some general usefulness in storing/exposing an SELinux
policy hash rather than only seeing it as duplicative property required
this measurement series?
Tyler
x feature, so you should
> be using SELINUX_STATE and SELINUX_POLICY, as I suggested
> before. Just because SELinux has state and policy to measure
> doesn't mean that a different module might not have other data,
> such as history, that should be covered as well.
In addition
On 2020-07-30 11:02:50, Lakshmi Ramasubramanian wrote:
> On 7/29/20 8:47 PM, Lakshmi Ramasubramanian wrote:
>
> Hi Tyler,
>
> > diff --git a/security/integrity/ima/Kconfig b/security/integrity/ima/Kconfig
> > index 080c53545ff0..86cba844f73c 100644
> > --- a/
On 2020-07-30 08:15:34, Lakshmi Ramasubramanian wrote:
> On 7/30/20 8:02 AM, Tyler Hicks wrote:
>
> > > diff --git a/security/integrity/ima/ima_policy.c
> > > b/security/integrity/ima/ima_policy.c
> > > index 07f033634b27..a0f5c39d9084 100644
> > >
to measure LSM state and LSM policy
> respectively. Return the status of the measurement operation from these
> two IMA hooks.
>
> Signed-off-by: Lakshmi Ramasubramanian
Reviewed-by: Tyler Hicks
Tyler
> ---
> include/linux/ima.h | 14 +
> se
rules with these specified hook functions when an
LSM that has measurement support is enabled. This messes up the ordering
of your patch series but it could be as simple as doing this:
else if (IS_ENABLED(CONFIG_SECURITY_SELINUX) &&
authors don't assume that
these policy language constructs are supported.
Fixes: 2b60c0ecedf8 ("IMA: Read keyrings= option from the IMA policy")
Fixes: 5808611cccb2 ("IMA: Add KEY_CHECK func to measure keys")
Suggested-by: Nayna Jain
Signed-off-by: Tyler Hicks
---
secu
d using "|" as an alternation delimiter is
becoming the norm in IMA policy.
This series is based on commit 311aa6aafea4 ("ima: move
APPRAISE_BOOTPARAM dependency on ARCH_POLICY to runtime") in
next-integrity.
Tyler
Tyler Hicks (2):
ima: Pre-parse the list of keyrings in
f keyrings was longer than what could
fit in the fixed size tbuf buffer in ima_policy_show().
Fixes: 5c7bac9fb2c5 ("IMA: pre-allocate buffer to hold keyrings string")
Fixes: 2b60c0ecedf8 ("IMA: Read keyrings= option from the IMA policy")
Signed-off-by: Tyler Hicks
---
securi
uct loop_device. Keep loop_ctl_mutex to protect global
> data such as loop_index_idr, loop_lookup, loop_add.
>
> Lock ordering: loop_ctl_mutex > lo_mutex.
>
> Signed-off-by: Pavel Tatashin
Thanks for the revision.
Reviewed-by: Tyler Hicks
Ty
On 2020-07-23 14:29:31, Pavel Tatashin wrote:
> Hi Tyler,
>
> Thank you for the review comments. My replies are inlined below.
>
> > > Scale it by introducing per-device lock: lo_mutex that proctests
> > > field in struct loop_device. Keep loop_ctl_mutex to prot
troy() in loop_remove().
> lo->lo_number = i;
> spin_lock_init(&lo->lo_lock);
> disk->major = LOOP_MAJOR;
> @@ -2272,15 +2274,21 @@ static long loop_control_ioctl(struct file *file,
> unsigned int cmd,
> ret =
On 2020-07-17 14:19:03, Tyler Hicks wrote:
> On 2020-07-17 14:56:46, Nayna wrote:
> >
> > On 7/9/20 2:19 AM, Tyler Hicks wrote:
> > > The KEY_CHECK function only supports the uid, pcr, and keyrings
> > > conditionals. Make this clear at policy load so that IMA
On 2020-07-17 15:20:22, Nayna wrote:
>
> On 7/9/20 2:19 AM, Tyler Hicks wrote:
> > Ask the LSM to free its audit rule rather than directly calling kfree().
>
> Is it to be called audit rule or filter rule ? Likewise in subject line.
The security hooks call this "audit r
On 2020-07-17 14:56:46, Nayna wrote:
>
> On 7/9/20 2:19 AM, Tyler Hicks wrote:
> > The KEY_CHECK function only supports the uid, pcr, and keyrings
> > conditionals. Make this clear at policy load so that IMA policy authors
> > don't assume that other conditionals
On 2020-07-17 13:40:22, Nayna wrote:
>
> On 7/9/20 2:19 AM, Tyler Hicks wrote:
> > The "appraise_flag" option is only appropriate for appraise actions
> > and its "blacklist" value is only appropriate when
> > CONFIG_IMA_APPRAISE_MODSIG is enabl
On 2020-07-17 18:35:03, Konsta Karsisto wrote:
> Hi,
>
> Found one glitch with this change, see below:
>
> On Thu, Jul 9, 2020 at 9:22 AM Tyler Hicks
> wrote:
> >
> > The args_p member is a simple string that is allocated by
> > ima_rule_init(). Shallow copy
On 2020-07-17 00:31:33, Mimi Zohar wrote:
> On Thu, 2020-07-09 at 01:18 -0500, Tyler Hicks wrote:
> > This series ultimately extends the supported IMA rule conditionals for
> > the KEXEC_CMDLINE hook function. As of today, there's an imbalance in
> > IMA langua
On 2020-07-16 14:14:50, Mimi Zohar wrote:
> On Thu, 2020-07-09 at 01:19 -0500, Tyler Hicks wrote:
> > The "appraise_flag" option is only appropriate for appraise actions
> > and its "blacklist" value is only appropriate when
> > CONFIG_IMA_APPRAISE_MODSI
think we should enforce that cap
here, too.
Thinking about it some more, I find it a little odd that we're spreading
the files necessary to update a policy across both procfs (sysctl) and
securityfs. It looks like procfs will have different semantics than
securityfs after looking at proc_sys_pe
On 2020-07-13 23:57:19, Jarkko Sakkinen wrote:
> On Fri, Jul 10, 2020 at 02:29:55PM -0500, Tyler Hicks wrote:
> > Require that the TCG_PCR_EVENT2.digests.count value strictly matches the
> > value of TCG_EfiSpecIdEvent.numberOfAlgorithms in the event field of the
> > TCG_PCCli
Rename IMA's internal audit rule functions from security_filter_rule_*()
to ima_filter_rule_*(). This avoids polluting the security_* namespace,
which is typically reserved for general security subsystem
infrastructure.
Signed-off-by: Tyler Hicks
Suggested-by: Casey Schaufler
---
1 - 100 of 926 matches
Mail list logo
