[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Add support for shipping extended attributes in debs



On Thu, May 3, 2018 at 8:39 AM Ian Jackson <ijackson@chiark.greenend.org.uk>
wrote:

> Matthew Garrett writes ("Re: Add support for shipping extended attributes
in debs"):
> > On Wed, May 2, 2018 at 5:39 AM Ian Jackson <
ijackson@chiark.greenend.org.uk>
> > wrote:
> > > Why do you want to ship security metadata and have dpkg apply it ?
> >
> > For our internal systems, we want to be able to distinguish between
> > binaries that have been produced by our internal build infrastructure
and
> > binaries that have been built locally or obtained from a third party. We
> > impose an LSM policy that distinguishes between "trusted" and
"untrusted"
> > binaries, and forbids untrusted binaries from accessing some sensitive
> > resources (such as credentials for access to production systems).
Trusted
> > binaries are signed at build time, and we verify that the signatures are
> > valid before allowing anything to execute in the trusted security
context.

> I see.  That's a nice explanation of the next layer up.  But I was
> hoping for a layer 9 anser.

I'm not sure I understand. In order to achieve this we need to ship the
signatures. The signatures are directly associated with the files. If dpkg
is installing the files then it also ought to be writing out the
signatures, otherwise things can end up out of sync - if a binary is
executed before the signature is written out then either it'll end up in
the untrusted tier or the kernel will block execution because the IMA or
EVM validation will fail.


Reply to: