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.
From a more generally practical perspective - Linux filesystem capabilities
are implemented using extended attributes, and right now dpkg has no way of
representing that. This means that packages that make use of filesystem
capabilities do so by running setcap in their postinst. This isn't
meaningfully parsable, so there's no good way to verify that the system
state is valid.
More niche - this could also be used to ship SELinux labels in band, rather
than having to fix up labeling after package install. I don't know whether
that would be something Debian would want, but it could be useful for some
special cases.
> Security mechanisms serve the interests of some people over others,
> and we should understand who we are helping and who we are hurting, so
> we can decide whether that's a good thing.
Absolutely. In itself any IMA or EVM signatures do nothing - the kernel
needs to be provided with a policy to restrict them, and that can be
overridden from the kernel command line. If a vendor is building a
Debian-based device that uses debs for updates and wants to lock down the
device such that users aren't able to run code of their choosing, this
would make it easier for them to do that. But I don't think we've seen many
cases of vendors trying to use Debian in that way.
My personal perspective is that making it easier for users to choose the
policy that they want to impose on their system is worthwhile, and if a
user wants to voluntarily lock down their system so it only runs software
that comes from official Debian repositories that's a thing they ought to
be able to do - as a hypothetical example, if non-free was signed with a
different key, a user would be able to ensure that their machine didn't run
any non-free software.
Reply to: