On Wed, Sep 04, 2013 at 09:37:47PM -0400, Josh Boyer wrote:
[..]
> > +config BINFMT_ELF_SIG
> > + bool "ELF binary signature verification"
> > + depends on BINFMT_ELF
> > + select INTEGRITY
> > + select INTEGRITY_SIGNATURE
> > + select INTEGRITY_ASYMMETRIC_KEYS
> > + select IMA
> > + select IMA_APPRAISE
> > + select SYSTEM_TRUSTED_KEYRING
> > + default n
> > + ---help---
> > + Check ELF binary signature verfication.
>
> Please don't do this. Yes, it's technically viable to select all the
> things you need, but this turns on entire subsystems we don't have
> enabled. In months when the maintainers have long forgotten about
> this, we have to go figure out what turned on INTEGRITY and IMA
> because they aren't explicitly set in the config-* fragments. It's
> really frustrating.
>
> Instead, please make BINFMT_ELF_SIG depend on
> INTEGRITY_ASYMMETRIC_KEYS and IMA_APPRAISE, then explicitly enable the
> options you need in config-x86-generic. Lump them together and
> include a comment at the top about what piece of functionality needs
> them.
Josh,
I don't think that will make lot of sense. When a user wants to enable
a feature, I think it is better that anything that feature depends on
is selected automatically.
I have had very frustating expriences when I do "make menuconfig" and
the options I want to enable are not there in menu because they are
depenedent on something else which is not enabled.
How on the earth a user is supposed to know that BINFMT_ELF_SIG is
dependent on IMA, IMA_APPRAISE, SYSTEM_TRUSTED_KEYRING
INTEGRITY_SIGNATURE, INTEGRITY_ASYMMETRIC_KEYS etc.
And we have precedence. CONFIG_MODULE_SIG selects all the component
it depends on.
[..]
> > +#ifdef CONFIG_BINFMT_ELF_SIG
> > + if (mlock_mappings) {
> > + retval = ima_appraise_file_digsig(system_trusted_keyring,
> > + bprm->file, signature, siglen);
> > + if (retval) {
> > + send_sig(SIGKILL, current, 0);
> > + goto out_free_dentry;
> > + }
> > + /* Signature verification successful */
> > + bprm->cred->proc_signed = true;
> > + }
> > +#endif
>
> If I'm understanding this correctly, it reads the file signature and
> marks the _process_ as signed, right? Is there anything that prevents
> a process marked in this way from exec'ing a new, unsigned, unverified
> executable?
Yep, an signed process can exec() and unsigned process without any issues.
Thanks
Vivek
_______________________________________________
kernel mailing list
kernel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/kernel
