linux-kernel - Re: [RFC PATCH] integrity: Use a new type for asymmetric signature

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 14 Mar 2013 23:08:45 +0200
From:	"Kasatkin, Dmitry" <dmitry.kasatkin@...el.com>
To:	Vivek Goyal <vgoyal@...hat.com>
Cc:	Mimi Zohar <zohar@...ux.vnet.ibm.com>,
	linux kernel mailing list <linux-kernel@...r.kernel.org>,
	linux-security-module@...r.kernel.org
Subject: Re: [RFC PATCH] integrity: Use a new type for asymmetric signature

On Thu, Mar 14, 2013 at 10:37 PM, Vivek Goyal <vgoyal@...hat.com> wrote:
> On Thu, Mar 14, 2013 at 04:30:28PM -0400, Vivek Goyal wrote:
>
> [..]
>> I thought explicitly using signature format is more intutive. Exporting
>> signature version is not. I personally associate versioning with minor
>> changes like addition of some fields etc.
>
> For instance, you might want to add some fields to  signature_v2_hdr down
> the line. I think even after that change, it still remains "asymmetric
> signature" just that structure size changes and there is additional
> info. If there is versioning info assciated with signature type
> ASYMMETRIC, we could simple bump it to 1.1 or whatever and keep the
> version detail internal to ima/integrity subsystem.
>

Yes, it will make some things cleaner.
We recently discussed with Mimi how to extend IMA with memory locking and
one of the ideas was to use a flag in the signature header to indicate
that we need
require memory locking. There we need new subversion of the asymmetric
signature type.

Please have a look to 3 top patches.

http://git.kernel.org/cgit/linux/kernel/git/kasatkin/linux-digsig.git/log/?h=working

It is a prototype to verify signature with arbitrary hash algorithm.
Top patch also locks the memory if executable is verified and it has
asymmetric signature type.
This unconditional locking is just for development and we might use
mlock bit from signature header.
Notice, that patch reset appraisal status when we get BPRM check and
there is a signature.

BTW, do you have a kernel repository somewhere.
It is often easier to understand and discuss when seeing "complete"
set of commits.
If patch is taken out of context, it might be a waste of time to
discuss unclear things.

- Dmitry

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