Hi Jann,
On Tue, 2020-05-05 at 02:15 +0200, Jann Horn wrote:
> On Mon, May 4, 2020 at 11:18 PM Mimi Zohar wrote:
> > Files can be mmap'ed read/write and later changed to execute to circumvent
> > IMA's mmap appraise policy rules. Due to locking issues (mmap semaphore
&g
e mprotect
PROT_EXECUTE change, if an mmap appraise policy rule exists.
On mprotect change success, return 0. On failure, return -EACESS.
Signed-off-by: Mimi Zohar
---
include/linux/ima.h | 7 ++
security/integrity/ima/ima_main.c | 50 +++
t this sort of message, in the future could you include this
patch (2/2) with your patch set? Please include the "Reviewed-by:
Lakshmi Ramasubramanian " tag.
thanks,
Mimi
>
> url:
> https://github.com/0day-ci/linux/commits/Mimi-Zohar/ima-extending-IMA-policy-to-support-in
bit set
- to support the new file open flag MAY_OPENEXEC introduced by Mickael
Salaun's "[PATCH v3 0/5] Add support for RESOLVE_MAYEXEC" patch set.
Mimi
Mimi Zohar (2):
ima: add policy support for identifying file execute mode bit
ima: add policy support for the new file op
Extend the IMA policy language with "mode=IXUGO" to identify files with
the execute mode bit enabled.
Examples:
measure func=FILE_CHECK mode=IXUGO
appraise func=FILE_CHECK appraise_type=imasig mode=IXUGO
Suggested-by: Steve Grubb (based on execute mode bit)
Signed-off-by:
:
measure func=FILE_CHECK mask=^MAY_OPENEXEC
appraise func=FILE_CHECK appraise_type=imasig mask=^MAY_OPENEXEC
Signed-off-by: Mimi Zohar
---
Documentation/ABI/testing/ima_policy | 2 +-
security/integrity/ima/ima_main.c| 3 ++-
security/integrity/ima/ima_policy.c | 15 +++
3
Hi Roberto,
On Mon, 2020-04-27 at 12:31 +0200, Roberto Sassu wrote:
> This patch fixes the return value of ima_write_policy() when a new policy
> is directly passed to IMA and the current policy requires appraisal of the
> file containing the policy. Currently, if appraisal is not in ENFORCE mode,
On Wed, 2019-10-23 at 13:52 -0400, Mimi Zohar wrote:
> On Wed, 2019-10-23 at 10:34 -0700, Lakshmi Ramasubramanian wrote:
> > On 10/23/19 6:23 AM, Mimi Zohar wrote:
> >
> > > The ordering of this patch set is awkward. It should first introduce
> > > a generic m
On Tue, 2019-10-22 at 17:18 -0700, Lakshmi Ramasubramanian wrote:
> diff --git a/security/security.c b/security/security.c
> index 250ee2d76406..707a9e7fa94d 100644
> --- a/security/security.c
> +++ b/security/security.c
> @@ -2303,6 +2303,16 @@ int security_key_getsecurity(struct key *key, char
>
On Wed, 2019-10-23 at 10:34 -0700, Lakshmi Ramasubramanian wrote:
> On 10/23/19 6:23 AM, Mimi Zohar wrote:
>
> > The ordering of this patch set is awkward. It should first introduce
> > a generic method for measuring keys based on the keyring. Then add
> > the additiona
On Wed, 2019-10-23 at 07:49 -0700, Lakshmi Ramasubramanian wrote:
> On 10/23/19 6:22 AM, Mimi Zohar wrote:
>
> Thanks for reviewing the changes Mimi.
> I'll address your comments and post an updated patch set shortly.
>
> >> Add a new ima hook to measure keys
On Tue, 2019-10-22 at 17:18 -0700, Lakshmi Ramasubramanian wrote:
> diff --git a/security/integrity/ima/ima_main.c
> b/security/integrity/ima/ima_main.c
> index 584019728660..8e965d18fb21 100644
> --- a/security/integrity/ima/ima_main.c
> +++ b/security/integrity/ima/ima_main.c
> @@ -610,14 +610,
On Tue, 2019-10-22 at 17:18 -0700, Lakshmi Ramasubramanian wrote:
> Call process_buffer_measurement to measure keys that
> are added and updated in the system.
This patch description doesn't describe what the patch actually does
(eg. it not only calls process_buffer_measurement, but defines the IM
On Tue, 2019-10-22 at 17:18 -0700, Lakshmi Ramasubramanian wrote:
> Add a new ima hook to measure keys added to builtin_trusted_keys
> keyring.
There is no IMA hook in this patch.
>
> Updated ima_match_rules function to handle the new ima hook.
> This is used to determine if ima policy requires
On Fri, 2019-10-04 at 09:37 -0700, James Bottomley wrote:
> On Thu, 2019-10-03 at 21:51 +0300, Jarkko Sakkinen wrote:
> > As has been seen recently, binding the buffer allocation and tpm_buf
> > together is sometimes far from optimal.
>
> Can you elaborate on this a bit more? I must have missed t
[Cc'ing David Safford]
On Thu, 2019-10-03 at 20:58 +0300, Jarkko Sakkinen wrote:
> On Thu, Oct 03, 2019 at 09:02:32AM -0400, Mimi Zohar wrote:
> > On Thu, 2019-10-03 at 14:41 +0300, Jarkko Sakkinen wrote:
> > > On Wed, Oct 02, 2019 at 10:00:19AM -0400, Mimi Zohar wrote:
>
On Thu, 2019-10-03 at 14:33 +0300, Jarkko Sakkinen wrote:
> > > Will this delay the TPM initialization, causing IMA to go into "TPM
> > > bypass mode"?
> >
> > Of course it will delay the init.
> >
> > As I've stated before the real fix for the bypass issue would be
> > to make TPM as part of th
On Thu, 2019-10-03 at 14:35 +0300, Jarkko Sakkinen wrote:
> On Wed, Oct 02, 2019 at 08:41:45AM -0400, Mimi Zohar wrote:
> > On Fri, 2019-09-27 at 16:06 +0300, Jarkko Sakkinen wrote:
> > > On Wed, Sep 25, 2019 at 10:03:46AM -0400, James Bottomley wrote:
> > > > On
On Thu, 2019-10-03 at 14:32 +0300, Jarkko Sakkinen wrote:
> On Wed, Oct 02, 2019 at 08:40:24AM -0400, Mimi Zohar wrote:
> > On Thu, 2019-09-26 at 16:12 +0300, Jarkko Sakkinen wrote:
> > > On Thu, Sep 26, 2019 at 03:46:35PM +0300, Jarkko Sakkinen wrote:
> > > > On W
On Tue, 2019-10-01 at 12:07 -0400, Nayna wrote:
>
> On 09/30/2019 09:04 PM, Thiago Jung Bauermann wrote:
> > Hello,
>
> Hi,
>
> >
> >> diff --git a/arch/powerpc/kernel/ima_arch.c
> >> b/arch/powerpc/kernel/ima_arch.c
> >> new file mode 100644
> >> index ..39401b67f19e
> >> --- /dev/
On Fri, 2019-09-27 at 16:06 +0300, Jarkko Sakkinen wrote:
> On Wed, Sep 25, 2019 at 10:03:46AM -0400, James Bottomley wrote:
> > On Wed, 2019-09-25 at 16:48 +0300, Jarkko Sakkinen wrote:
> > [...]
> > > + data_page = alloc_page(GFP_HIGHUSER);
> > > + if (!data_page)
> > > + return -ENOMEM;
On Thu, 2019-09-26 at 16:12 +0300, Jarkko Sakkinen wrote:
> On Thu, Sep 26, 2019 at 03:46:35PM +0300, Jarkko Sakkinen wrote:
> > On Wed, Sep 25, 2019 at 04:48:41PM +0300, Jarkko Sakkinen wrote:
> > > - tpm_buf_reset(&buf, TPM2_ST_NO_SESSIONS, TPM2_CC_GET_RANDOM);
> > > + tpm_buf_res
On Mon, 2019-09-16 at 18:13 -0400, Mimi Zohar wrote:
> On Mon, 2019-09-16 at 13:38 -0700, Linus Torvalds wrote:
> > On Wed, Sep 11, 2019 at 2:29 PM Mimi Zohar wrote:
> > >
> > > The major feature in this pull request is IMA support for measuring
> > > and appr
On Mon, 2019-09-16 at 13:38 -0700, Linus Torvalds wrote:
> On Wed, Sep 11, 2019 at 2:29 PM Mimi Zohar wrote:
> >
> > The major feature in this pull request is IMA support for measuring
> > and appraising appended file signatures. In addition are a couple of
> > bug fi
: Use struct_size() in kzalloc() (2019-08-29 14:23:30 -0400)
Gustavo A. R. Silva (2):
ima: use struct_size() in kzalloc()
ima: ima_api: Use struct_size() in kzalloc()
Mimi Zohar (2):
ima: initialize the "tem
Hi Prakhar,
On Fri, 2019-09-06 at 16:56 -0700, prsriva wrote:
> On 8/30/19 5:11 PM, Thiago Jung Bauermann wrote:
> > Hello Prakhar,
> >
> > Answering this part from the cover letter:
> >
> >> The code is in most part same as powerpc, i want to get feedback as to
> >> how/correct way to refactor th
Hi Gustavo,
On Wed, 2019-08-28 at 13:29 -0500, Gustavo A. R. Silva wrote:
> On 5/29/19 11:53 AM, Gustavo A. R. Silva wrote:
> > One of the more common cases of allocation size calculations is finding
> > the size of a structure that has a zero-sized array at the end, along
> > with memory for some
On Wed, 2019-08-28 at 20:38 -0300, Thiago Jung Bauermann wrote:
> Hello Mimi,
>
> Mimi Zohar writes:
>
> > In addition to the PE/COFF and IMA xattr signatures, the kexec kernel
> > image can be signed with an appended signature, using the same
> > scripts/sign-
On Wed, 2019-08-28 at 13:29 -0500, Gustavo A. R. Silva wrote:
> Hi all,
>
> Friendly ping:
>
> Who can take this, please?
Thank you for the reminder. I'm just getting back from LSS and a very
short vacation. I'll look at it shortly.
Mimi
On Wed, 2019-08-28 at 09:53 -0600, shuah wrote:
> On 8/28/19 9:14 AM, Mimi Zohar wrote:
> > In addition to the PE/COFF and IMA xattr signatures, the kexec kernel
> > image can be signed with an appended signature, using the same
> > scripts/sign-file tool that is used t
On Wed, 2019-08-28 at 08:45 -0600, shuah wrote:
> Hi Mimi,
>
> On 8/28/19 6:39 AM, Mimi Zohar wrote:
> > Detect and allow appended signatures.
> >
>
> Can you please add a couple of more sentences on the feature
> and what happens without it? I know this is a test
existing test messages
appropriately.
Reviewed-by: Petr Vorel
Signed-off-by: Mimi Zohar
---
.../selftests/kexec/test_kexec_file_load.sh| 38 +++---
1 file changed, 34 insertions(+), 4 deletions(-)
diff --git a/tools/testing/selftests/kexec/test_kexec_file_load.sh
b/tools
Hi Gustavo,
On Sun, 2019-08-11 at 18:55 -0500, Gustavo A. R. Silva wrote:
> hdr is being freed and then dereferenced by accessing hdr->pkcs7_msg
>
> Fix this by copying the value returned by PTR_ERR(hdr->pkcs7_msg) into
> automatic variable err for its safe use after freeing hdr.
>
> Addresses-C
Detect and allow appended signatures.
Signed-off-by: Mimi Zohar
---
.../selftests/kexec/test_kexec_file_load.sh| 38 +++---
1 file changed, 34 insertions(+), 4 deletions(-)
diff --git a/tools/testing/selftests/kexec/test_kexec_file_load.sh
b/tools/testing/selftests
On Fri, 2019-08-16 at 14:36 +0100, David Howells wrote:
> Mimi Zohar wrote:
>
> > Sorry for the delay. An exception is needed for loading builtin keys
> > "KEY_ALLOC_BUILT_IN" onto a keyring that is not writable by userspace.
> > The following works, but prob
On Fri, 2019-08-16 at 14:36 +0100, David Howells wrote:
> Mimi Zohar wrote:
>
> > Sorry for the delay. An exception is needed for loading builtin keys
> > "KEY_ALLOC_BUILT_IN" onto a keyring that is not writable by userspace.
> > The following works, but prob
Hi Stephen,
On Tue, 2019-08-06 at 13:45 +1000, Stephen Rothwell wrote:
> Hi Thiago,
>
> On Tue, 06 Aug 2019 00:18:06 -0300 Thiago Jung Bauermann
> wrote:
> >
> > Sorry for the trouble. I wasn't aware of that build time check.
> > I'll enable HEADER_TEST and KERNEL_HEADER_TEST for my next patche
On Mon, 2019-08-05 at 16:50 +0200, Roberto Sassu wrote:
> Regarding Mimi's proposal to avoid the issue by extending the PCR with
> zeros, I think it also achieve the goal.
Roberto, removing the following code from init_digests() would be the
equivalent to the prior code, without needing to make a
On Fri, 2019-08-02 at 09:42 +0800, Jia Zhang wrote:
>
> On 2019/8/2 上午6:57, Mimi Zohar wrote:
> > Hi Jia,
> >
> > On Thu, 2019-08-01 at 09:23 +0800, Jia Zhang wrote:
> >> Similar to .ima, the cert imported to .ima_blacklist is able to be
> >
On Sat, 2019-08-03 at 17:44 +0300, Jarkko Sakkinen wrote:
> On Fri, 2019-08-02 at 15:23 -0500, Tyler Hicks wrote:
> > That wasn't the conclusion that I came to. I prefer Robert's proposed
> > change to trusted.ko.
> >
> > How do you propose that this be fixed in eCryptfs?
> >
> > Removing encrypt
Hi Jia,
On Thu, 2019-08-01 at 09:23 +0800, Jia Zhang wrote:
> Similar to .ima, the cert imported to .ima_blacklist is able to be
> authenticated by a secondary CA cert.
>
> Signed-off-by: Jia Zhang
The IMA blacklist, which is defined as experimental for a reason, was
upstreamed prior to the sys
Hi Eric,
> > the existing dependency chain (in reverse order) is:
> >
> > -> #1 (&mm->mmap_sem#2){}:
> > down_read+0x3f/0x1e0 kernel/locking/rwsem.c:24
> > get_user_pages_unlocked+0xfc/0x4a0 mm/gup.c:1174
> > __gup_longterm_unlocked mm/gup.c:2193 [inline]
> > g
Hi Eric,
On Mon, 2019-06-03 at 09:35 -0700, syzbot wrote:
> syzbot has found a reproducer for the following crash on:
>
> HEAD commit:3c09c195 Add linux-next specific files for 20190531
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=10f61a0ea0
> k
Hi Eric,
On Mon, 2019-06-03 at 09:35 -0700, syzbot wrote:
> syzbot has found a reproducer for the following crash on:
>
> HEAD commit:3c09c195 Add linux-next specific files for 20190531
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=10f61a0ea0
> k
Hi Linus,
On Wed, 2019-07-10 at 18:59 -0700, Linus Torvalds wrote:
> Anyway, since it does seem like David is offline, I've just reverted
> this from my tree, and will be continuing my normal merge window pull
> requests (the other issues I have seen have fixes in their respective
> trees).
Sorry
On Tue, 2019-07-09 at 19:24 +0300, Jarkko Sakkinen wrote:
> On Mon, Jul 08, 2019 at 01:34:59PM -0700, James Bottomley wrote:
> > Not a criticism of your patch, but can we please stop doing this.
> > Single random number sources are horrendously bad practice because it
> > gives an attacker a singl
Hi Stephen,
On Tue, 2019-07-09 at 10:11 +1000, Stephen Rothwell wrote:
> > diff --cc security/integrity/digsig.c
> > index 868ade3e8970,e432900c00b9..
> > --- a/security/integrity/digsig.c
> > +++ b/security/integrity/digsig.c
> > @@@ -69,9 -70,8 +70,9 @@@ int integrity_digsig_verify(c
Hi Jarkko,
On Mon, 2019-07-08 at 18:11 +0300, Jarkko Sakkinen wrote:
> On Sat, 2019-07-06 at 20:18 -0400, Nayna Jain wrote:
> > +/*
> > + * tpm_get_pcr_allocation() - initialize the chip allocated banks for PCRs
> > + * @chip: TPM chip to use.
> > + */
> > +static int tpm_get_pcr_allocation(struct
(2):
LSM: switch to blocking policy update notifiers
ima: use the lsm policy update notifier
Matthew Garrett (1):
IMA: support for per policy rule template formats
Mimi Zohar (2):
x86/ima: check EFI SetupMode too
ima: prevent a file already mmap'ed write to be mm
Hi Jarkko,
On Thu, 2019-07-04 at 07:48 -0400, Mimi Zohar wrote:
> On Thu, 2019-07-04 at 13:28 +0200, Roberto Sassu wrote:
> > On 7/4/2019 12:03 PM, Jarkko Sakkinen wrote:
> > > On Mon, 2019-07-01 at 15:15 +0200, Michal Suchanek wrote:
> >
xes: 879b589210a9 ("tpm: retrieve digest size of unknown algorithms with
> PCR read")
> Signed-off-by: Nayna Jain
Reviewed-by: Mimi Zohar
On Thu, 2019-07-04 at 13:28 +0200, Roberto Sassu wrote:
> On 7/4/2019 12:03 PM, Jarkko Sakkinen wrote:
> > On Mon, 2019-07-01 at 15:15 +0200, Michal Suchanek wrote:
> >> This reverts commit 0b6cf6b97b7ef1fa3c7fefab0cac897a1c4a3400 to avoid
> >> following crash:
> >
> > Thank you. I think this the
On Wed, 2019-07-03 at 09:16 +, David Laight wrote:
> > diff --git a/security/integrity/ima/ima_template_lib.c
> > b/security/integrity/ima/ima_template_lib.c
> > index 9fe0ef7f91e2..05636e9b19b1 100644
> > --- a/security/integrity/ima/ima_template_lib.c
> > +++ b/security/integrity/ima/ima_te
On Thu, 2019-06-27 at 20:25 -0300, Thiago Jung Bauermann wrote:
> MAX_TEMPLATE_NAME_LEN is used when restoring measurements carried over from
> a kexec. It should be set to the length of a template containing all fields
> except for 'd' and 'n', which don't need to be accounted for since they
> sho
On Mon, 2019-06-24 at 19:03 -0300, Thiago Jung Bauermann wrote:
> Hello Prakhar,
>
> Prakhar Srivastava writes:
>
> > diff --git a/security/integrity/ima/ima_template.c
> > b/security/integrity/ima/ima_template.c
> > index 00dd5a434689..a01a17e5c581 100644
> > --- a/security/integrity/ima/ima_t
[Cc'ing David Howells]
On Wed, 2019-06-26 at 11:35 -0700, Randy Dunlap wrote:
> On 6/26/19 6:16 AM, Stephen Rothwell wrote:
> > Hi all,
> >
> > The sparc64 builds are broken in this tree, sorry.
> >
> > Changes since 20190625:
> >
>
> on x86_64:
>
> 11 warnings like this one (in a randconfig
Hi Prakhar,
On Sun, 2019-06-23 at 23:23 -0700, Prakhar Srivastava wrote:
> Currently during soft reboot(kexec_file_load) boot command line
> arguments are not measured. Define hooks needed to measure kexec
> command line arguments during soft reboot(kexec_file_load).
>
> - A new ima hook ima_kexe
On Thu, 2019-06-20 at 18:19 -0700, Matthew Garrett wrote:
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -2239,6 +2239,15 @@
> lockd.nlm_udpport=M [NFS] Assign UDP port.
> Format:
>
> + loc
t; Signed-off-by: Prakhar Srivastava
With minor changes below,
Reviewed-by: Mimi Zohar
> ---
> diff --git a/security/integrity/ima/ima_main.c
> b/security/integrity/ima/ima_main.c
> index af341a80118f..1e233417a7af 100644
> --- a/security/integrity/ima/ima_main.c
> +++ b
On Wed, 2019-06-19 at 11:08 -0700, prakhar srivastava wrote:
>
> > > if (iint->measured_pcrs & (0x1 << pcr))
> > > diff --git a/security/integrity/ima/ima_init.c
> > > b/security/integrity/ima/ima_init.c
> > > index 993d0f1915ff..c8591406c0e2 100644
> > > --- a/security/integrity/ima/ima_in
On Mon, 2019-06-17 at 11:35 -0700, Prakhar Srivastava wrote:
> A buffer(kexec boot command line arguments) measured into IMA
> measuremnt list cannot be appraised, without already being
> aware of the buffer contents. Since hashes are non-reversible,
> raw buffer is needed for validation or regener
On Tue, 2019-06-18 at 20:06 +0200, Arnd Bergmann wrote:
> On Tue, Jun 18, 2019 at 3:55 PM Mimi Zohar wrote:
> >
> > On Mon, 2019-06-17 at 22:08 +0200, Arnd Bergmann wrote:
> > > On Mon, Jun 17, 2019 at 8:08 PM Mimi Zohar wrote:
> > > >
> > > > On
On Mon, 2019-06-17 at 22:08 +0200, Arnd Bergmann wrote:
> On Mon, Jun 17, 2019 at 8:08 PM Mimi Zohar wrote:
> >
> > On Mon, 2019-06-17 at 11:55 -0400, Mimi Zohar wrote:
> > > On Mon, 2019-06-17 at 13:20 +0200, Arnd Bergmann wrote:
> > > > On 32-bit ARM, we
ARE) returns -EACCES. This happens because a
> zero-on-success return value is cast to a bool that's true on success.
>
> Fix the return value handling so we get the correct behaviour.
Reviewed-by: Mimi Zohar
On Mon, 2019-06-17 at 11:55 -0400, Mimi Zohar wrote:
> On Mon, 2019-06-17 at 13:20 +0200, Arnd Bergmann wrote:
> > On 32-bit ARM, we get a warning about excessive stack usage when
> > building with clang.
> >
> > security/integrity/ima/ima_crypto.c:504:5: error: stack f
On Mon, 2019-06-17 at 13:20 +0200, Arnd Bergmann wrote:
> On 32-bit ARM, we get a warning about excessive stack usage when
> building with clang.
>
> security/integrity/ima/ima_crypto.c:504:5: error: stack frame size
> of 1152 bytes in function 'ima_calc_field_array_hash' [-Werror,-
> Wframe-large
> > > diff --git a/security/integrity/ima/ima_init.c
> > > b/security/integrity/ima/ima_init.c
> > > index 993d0f1915ff..c8591406c0e2 100644
> > > --- a/security/integrity/ima/ima_init.c
> > > +++ b/security/integrity/ima/ima_init.c
> > > @@ -50,7 +50,7 @@ static int __init ima_add_boot_aggregate(
Hi Stephen,
On Fri, 2019-06-14 at 15:34 +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the integrity tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> drivers/infiniband/core/device.c: In function 'ib_core_init':
> drivers/infiniband/core/device.c:2531:
Hi Prakhar,
> > diff --git a/security/integrity/ima/ima_api.c
> > b/security/integrity/ima/ima_api.c
> > index ea7d8cbf712f..83ca99d65e4b 100644
> > --- a/security/integrity/ima/ima_api.c
> > +++ b/security/integrity/ima/ima_api.c
> > @@ -140,7 +140,7 @@ void ima_add_violation(struct file *file,
On Wed, 2019-06-12 at 15:15 -0700, Prakhar Srivastava wrote:
> The kexec cmdline hash is stored in the "d-ng" field of the template data.
> and can be verified using
> sudo cat /sys/kernel/security/integrity/ima/ascii_runtime_measurements |
> grep kexec-cmdline | cut -d' ' -f 6 | xxd -r -p | s
On Wed, 2019-06-12 at 15:15 -0700, Prakhar Srivastava wrote:
> During soft reboot(kexec_file_load) boot cmdline args
Any reason for not spelling it out and using the "boot command line"?
> are not measured.Thus the new kernel on load boots with
> an assumption of cold reboot.
Double spaces after
On Wed, 2019-06-12 at 15:15 -0700, Prakhar Srivastava wrote:
As before, the patch title needs to be prefixed with "ima: ".
> /* IMA template field data definition */
> diff --git a/security/integrity/ima/ima_api.c
> b/security/integrity/ima/ima_api.c
> index ea7d8cbf712f..83ca99d65e4b 100644
>
Hi Prakhar,
Patches titles in the subject line need to be prefixed with the
subsystem, in this case "ima: ".
On Wed, 2019-06-12 at 15:15 -0700, Prakhar Srivastava wrote:
> This patch adds support in ima to measure kexec cmdline args
> during soft reboot(kexec_file_load).
Based on the patch title
On Tue, 2019-06-11 at 21:40 +0800, YueHaibing wrote:
> Fix sparse warning:
>
> security/integrity/ima/ima_policy.c:202:23: warning:
> symbol 'arch_policy_entry' was not declared. Should it be static?
>
> Reported-by: Hulk Robot
> Signed-off-by: YueHaibing
Thanks, this patch has been queued to
ting is off is the call to
ima_get_action() in process_buffer_measurement() and the call to
process_buffer_measurement() in ima_kexec_cmdline().
thanks,
Mimi
>
> Changelog:
> V7:
> - rebased to next-queued-testing
>
> https://git.kernel.org/pub/scm/linux/kernel/git/zoha
On Mon, 2019-06-03 at 15:04 -0700, syzbot wrote:
> syzbot has bisected this bug to:
>
> commit 69d61f577d147b396be0991b2ac6f65057f7d445
> Author: Mimi Zohar
> Date: Wed Apr 3 21:47:46 2019 +
>
> ima: verify mprotect change is consistent with mmap policy
>
Hi Linus,
Included in this pull request are four bug fixes, which are not
specific to 5.2. The first two are related to the architecture
specific IMA policy support. The other two patches, one is related to
EVM signatures, based on additional hash algorithms, and the other is
related to displayi
On Wed, 2019-05-29 at 15:30 +0200, Roberto Sassu wrote:
> Show the '^' character when a policy rule has flag IMA_INMASK.
>
> Fixes: 80eae209d63ac ("IMA: allow reading back the current IMA policy")
> Signed-off-by: Roberto Sassu
> Cc: sta...@vger.kernel.org
Thanks, queued.
> ---
> security/inte
On Fri, 2019-05-24 at 12:00 -0700, prakhar srivastava wrote:
> On Fri, May 24, 2019 at 11:09 AM Mimi Zohar wrote:
> >
> > > >> As mentioned, the first patch description should include a shell
> > > >> command for verifying the digest in the kexec boot comman
> >> As mentioned, the first patch description should include a shell
> >> command for verifying the digest in the kexec boot command line
> >> measurement list record against /proc/cmdline. This patch description
> >> should include a shell command showing how to verify the digest based
> >> on t
On Mon, 2019-05-20 at 17:06 -0700, Prakhar Srivastava wrote:
> A buffer(cmdline args) measured into ima cannot be appraised
> without already being aware of the buffer contents.Since we
> don't know what cmdline args will be passed (or need to validate
> what was passed) it is not possible to appra
Hi Prakhar,
On Mon, 2019-05-20 at 17:06 -0700, Prakhar Srivastava wrote:
> Currently during kexec_file_load(soft reboot) the cmdline args
> passed are not measured and the PCR values are not reset.
This patch addresses not measuring the kexec boot cmdline. I don't
see a reason for mentioning any
On Thu, 2019-05-16 at 18:12 +0200, Roberto Sassu wrote:
> diff --git a/Documentation/admin-guide/kernel-parameters.txt
> b/Documentation/admin-guide/kernel-parameters.txt
> index 52e6fbb042cc..80e1c233656b 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-g
On Thu, 2019-05-16 at 18:12 +0200, Roberto Sassu wrote:
> This patch prevents memory access beyond the evm_tfm array by checking the
> validity of the index (hash algorithm) passed to init_desc(). The hash
> algorithm can be arbitrarily set if the security.ima xattr type is not
> EVM_XATTR_HMAC.
>
On Wed, 2019-05-15 at 11:17 -0700, Lakshmi wrote:
> Hi Mimi,
>
> I would like to make sure I understood your feedback.
>
> >
> > Why duplicate the certificate info on each record in the measurement
> > list? Why not add the certificate info once, as the key is loaded
> > onto the .ima and .plat
On Thu, 2019-05-16 at 01:29 -0400, Arvind Sankar wrote:
> I think that's a separate issue. If you want to allow people to be able
> to put files onto the system that will be IMA verified, they need to
> have some way to locally sign them whether it's inside an initramfs or
> on a real root filesys
On Tue, 2019-05-14 at 10:14 -0700, Lakshmi wrote:
> The motive behind this patch series is to measure the public key
> of the IMA signature signer in the IMA log.
>
> The IMA signature of the file, logged using ima-sig template, contains
> the key identifier of the key that was used to generate th
[Cc'ing Dave Young]
On Fri, 2019-05-10 at 15:37 -0700, Prakhar Srivastava wrote:
> From: Prakhar Srivastava
The "From" line above should only appear when the patch author and the
sender differ. You can create the patches under one id and post them
from another id. Something is still wrong.
>
> > > +{
> > > +
> > > + if (action & IMA_MEASURE)
> > > + ret = ima_store_template(entry, violation, NULL, buf, pcr);
> > > +
> > > + if (action & IMA_AUDIT)
> > > + ima_audit_measurement(iint, event_data.filename);
> >
> > The cover letter and patch description s
Hi Thiago,
On Thu, 2019-04-18 at 00:51 -0300, Thiago Jung Bauermann wrote:
>
> @@ -326,6 +356,10 @@ int ima_appraise_measurement(enum ima_hooks func,
> case INTEGRITY_UNKNOWN:
> break;
> case INTEGRITY_NOXATTRS:/* No EVM protected xattrs. */
> +
On Mon, 2019-05-13 at 14:47 -0400, Arvind Sankar wrote:
> On Mon, May 13, 2019 at 02:36:24PM -0400, Mimi Zohar wrote:
> >
> > > > How does this work today then? Is it actually the case that initramfs
> > > > just cannot be used on an IMA-enabled system, or
> > How does this work today then? Is it actually the case that initramfs
> > just cannot be used on an IMA-enabled system, or it can but it leaves
> > the initramfs unverified and we're trying to fix that? I had assumed the
> > latter.
> Oooh, it's done not by starting IMA appraisal later, but b
On Fri, 2019-05-10 at 15:37 -0700, Prakhar Srivastava wrote:
> +/*
> + * process_buffer_measurement - Measure the buffer passed to ima log.
"passed to ima log" is unnecessary.
> + * (Instead of using the file hash use the buffer hash).
This comment, if needed, belongs in the text description ar
On Mon, 2019-05-13 at 04:07 -0500, Rob Landley wrote:
> > Allowing a kernel with integrity enforcement to parse the CPIO image
> > without verifying it first is the weak point.
>
> If you don't verify the CPIO image then in theory it could have anything in
> it,
> yes. You seem to believe that s
On Sun, 2019-05-12 at 17:31 +0200, Dominik Brodowski wrote:
> On Sun, May 12, 2019 at 08:52:47AM -0400, Mimi Zohar wrote:
> > It's too late. The /init itself should be signed and verified.
>
> Could you elaborate a bit more about the threat model, and why deferring
> t
On Sun, 2019-05-12 at 11:17 +0200, Dominik Brodowski wrote:
> On Thu, May 09, 2019 at 01:24:17PM +0200, Roberto Sassu wrote:
> > This proposal consists in marshaling pathnames and xattrs in a file called
> > .xattr-list. They are unmarshaled by the CPIO parser after all files have
> > been extracte
On Fri, 2019-05-10 at 15:46 -0500, Rob Landley wrote:
> On 5/10/19 6:49 AM, Mimi Zohar wrote:
> > On Fri, 2019-05-10 at 08:56 +0200, Roberto Sassu wrote:
> >> On 5/9/2019 8:34 PM, Rob Landley wrote:
> >>> On 5/9/19 6:24 AM, Roberto Sassu wrote:
> >
> &g
On Fri, 2019-05-10 at 08:56 +0200, Roberto Sassu wrote:
> On 5/9/2019 8:34 PM, Rob Landley wrote:
> > On 5/9/19 6:24 AM, Roberto Sassu wrote:
> >> The difference with another proposal
> >> (https://lore.kernel.org/patchwork/cover/888071/) is that xattrs can be
> >> included in an image without cha
ima_file_mmap() for mprotect changes.
Suggested-by: Stephen Smalley
Signed-off-by: Mimi Zohar
---
security/security.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/security/security.c b/security/security.c
index 23cbb1a295a3..98ce27933e72 100644
--- a/security/secur
sing the integrity of a file
being mmap'ed execute, without first making sure the file cannot be
modified, makes no sense. This patch prevents files, in policy, already
mmap'ed write, from being mmap'ed execute.
Signed-off-by: Mimi Zohar
---
security/integr
401 - 500 of 1508 matches
Mail list logo
