Re: [Suit] Surprising push back on the need for a customer to verify the trust relationship between a software supplier and software signer during digital signature validation on signed code

[Phillip Hallam-Baker <[e-mail]>]

On Fri, Jun 11, 2021 at 6:50 PM Michael Richardson <[e-mail]>
wrote:

>
> Phillip Hallam-Baker <[e-mail]> wrote:
>     > Authenticode only signed the software distribution package, most of
>     > what has followed has done the same. That is a useful control of
> course
>     > because an installer is an executable that runs on the machine. But
> it
>     > is necessary but not sufficient: Every executable, every piece of
>     > installed data should be signed without exception.
>
> I think that there are existing mechanisms to embed signatures in ELF.
> There was a lot of discussion, I think, about how the signature was visible
> or not visible to regular tools.  Some mechanisms basically hid the
> signature
> at the end of the file, pretending that the file was shorter when treated
> as
> an executable.
> Other people wanted it in some other resource record, but then there were
> concerns that the signatures would get lost in backups, etc.
>
> So there have been patches to Linux to verify the signatures before
> executing.  I think that this has been done on other platforms, and there
> are
> even MCUs that can verify and even decrypt code transparently as it is
> executable.
>
> Are you thinking at this level?   Always?  Sometimes?
>

Given that this is a submission to govt. I am not particularly concerned
with the normal process of socializing a proposal in the Linux proposal.

This is the sort of area where if govt. sets a specific, achievable
requirement and puts up a relatively modest amount of cash, change is going
to happen. And don't forget that the reason Ubuntu exists in the first
place is that Mark Shuttleworth (appropriately) had a bee in his bonnet
about code signing. I really don't see this as a heavy lift

The harder part is all the checking and certification that has to take
place in order to know that a theoretical security control is an actual
one. It takes quite a bit to make something the default. But this is
something that a lot of parties have interests that could be met at the
same time.

Take Java and .NET code. Both require a runtime library support to run.
Both seek to provide cross platform binary compatibility. Wouldn't it be
nice if there was an industry standard agreement on one packaging format
for an executable that will work on Windows, Linux and MacOS on any CPU?

If we want to get really serious, we will need hardware support so that
file digests are checked as pages are mapped into memory.




>     > am merely saying that they have to define one, they have to show that
>     > all the necessary operations are inside it and that everything inside
>     > it is sufficiently secure.
>
> I think that there is an additional part: resilience of the whole to
> failures
> of the pieces.   Having one large perimeter is not as good as having many
> small ones, except some consideration of economies of scale.
>

Yes, and I am happy to leave that part of the problem to those concerned
with specific deployments.



> ...
>
>     > It is worth pointing out that the reason colonial pipeline was
> affected
>     > so badly was probably that they were sending multiple types of fuel
>     > down the same pipe in batches. That game is only going to work if you
>     > can absolutely guarantee that you aren't going to put the load of tar
>     > into a tank full of top grade aviation fuel. So their problem
> probably
>     > wasn't on their actual operations side itself, the thing they were
>     > looking at. They had not understood that the database of what fuel is
>     > where was actually critical to operations.
>
> So that was really their problem, they lost their inventory list?
>

That is my informed guess after reviewing some non public info and reading
between the lines in various communications.