linux-kernel - Re: [PATCH 2/3] binfmt_elf: Verify signature of signed elf binary

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Thu, 17 Jan 2013 12:36:05 -0500
From:	Vivek Goyal <vgoyal@...hat.com>
To:	Mimi Zohar <zohar@...ux.vnet.ibm.com>
Cc:	linux-kernel@...r.kernel.org, ebiederm@...ssion.com,
	pjones@...hat.com, hpa@...or.com, dhowells@...hat.com,
	jwboyer@...hat.com
Subject: Re: [PATCH 2/3] binfmt_elf: Verify signature of signed elf binary

On Thu, Jan 17, 2013 at 11:32:45AM -0500, Mimi Zohar wrote:

[..]
> > > At this point, why would you want yet another method for signing files?
> > 
> > Are you saying that append signature instead of putting them in a section
> > or are you saying that just use IMA.
> > 
> > - For the first, I am fine with appending too if that works better. So
> >   what's wrong with current implementation. Just because we append the
> >   signatures in case of modules, we should follow the same thing for
> >   executables too?
> 
> No, I was saying that if this patch set were to be upstreamed, then the
> signature verification, at least for ELF modules and ELF executables,
> should be the same.  The patch would then be a lot smaller.

I don't think that patch is lot smaller. Initially I had written code
where signatures were appended. Parsing the signature is little different
from module. In case of modules, whole file is already in memory and
in case of executables, we are reading selected portions of file in
buffer. 

So we don't share code while parsing, hence there is no significant
code bloat when .signature section is added as opposed to appending
signature.

> 
> > - If above comment is w.r.t use of IMA, then I have no issues in using
> >   IMA as long as it can meet all the requirements. Looks like there is
> >   a long TODO list before we get there. In fact for some things its not
> >   even clear whether they fit in IMA or somehwere else.
> > 
> >   - Make sure IMA/EVM stuff chains into secureboot chain of trust.
> 
> For sure.
> 
> >   - Sort out all the memory locking related issues I mentioned in
> >     other mail. You seemed to be of opinion that it is out of scope
> >     for IMA, but I think it probably is nice extenstion.
> 
> Yes, it would be, but I'm not sure that your method of mmaping a file
> with MAP_LOCKED is scalable, when all executables are signed.  If it is,
> then why not do it in general?  Otherwise there needs to be a more
> scalable solution.

It is like running without swap enabled. There is definitely a cost
involved and I think that justfies that to begin with why not everything
should be signed. Probably a overkill.

And hence the idea of signing only very selected files on need basis.

Those who want to lock down full user space, they can happily sign full
user space and pay the penalty. But for general case, it might not make
sense.

Encrypted swap is one workaround. Which probably is more scalable then
locking down all user space in memory. But that question arises only
if we want to sign full user space in general case. And I think we 
agree that it does not make much sense.

> 
> >     Or somehow a way needs to be found to make sure nobody can modify
> >     process address space without processe's knowledge.
> 
> I'm not sure I understand.  Does your patch already address this?

Well, I was repeating the same thing in ohter words. So if we do
following.

	- No shared libaries
	- No ptrace
	- Lock down current and future mappings so nothing is swapped out.

Will it not make sure that a process address space is not modified without
process knowledge. I think my patch has little bug. I might not have
enabled a flag to lock down future mappings.

> 
> >   - Once all this works, then one needs to figure out all the RPM stuff
> >     and plugins to make sure files can be singed on build server and
> >     installed properly on target system.
> 
> Yes, we need the distros involvment in this to sign all files.
> Immutable files should be signed with digital signatures.

So you still think that I should take IMA path to solve my use case or it
is reasonable to sign executable directly and I continue down my path.

Thanks
Vivek
--
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/