[Fedora 09/19] binfmt_elf: Elf executable signature verification

Vivek Goyal vgoyal at redhat.com
Thu Sep 5 02:07:33 UTC 2013


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


More information about the kernel mailing list