Messages in this thread | | | Date | Thu, 14 Mar 2013 23:08:45 +0200 | Subject | Re: [RFC PATCH] integrity: Use a new type for asymmetric signature | From | "Kasatkin, Dmitry" <> |
| |
On Thu, Mar 14, 2013 at 10:37 PM, Vivek Goyal <vgoyal@redhat.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@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
| |