Re: Add support for shipping extended attributes in debs
On Fri, May 4, 2018 at 4:12 AM Ian Jackson <firstname.lastname@example.org>
> Matthew Garrett writes ("Re: Add support for shipping extended attributes
> > On Thu, May 3, 2018 at 8:39 AM Ian Jackson <
> > wrote:
> > > 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
> > 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.
> Who wants the unapproved binaries to run, and who wants to prevent
> them from running, and (in each case) why ?
For our case: we don't want binaries of unknown provenance to have access
to sensitive credentials. Attackers who've compromised user accounts do.
We're not actually seeking to block execution of unsigned binaries, we just
want unsigned binaries to run in a less privileged security domain.