[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1596735649.25458.15.camel@linux.ibm.com>
Date: Thu, 06 Aug 2020 10:40:49 -0700
From: James Bottomley <jejb@...ux.ibm.com>
To: Jonas Witschel <diabonas@...hlinux.org>, oss-security@...ts.openwall.com
Cc: trousers-tech@...ts.sourceforge.net, security@...e.de
Subject: Re: Multiple Security
Issues in the TrouSerS tpm1.2 tscd Daemon
On Thu, 2020-08-06 at 13:06 +0200, Jonas Witschel wrote:
> On 2020-08-05 14:51, Jerry Snitselaar wrote:
> > > Mitigation and Bugfixes
> > > =======================
> > >
> > > It seems best to me to run the tcsd as the tss:tss user and group
> > > right away and to not rely on the privilege drop logic
> > > implemented in the daemon itself. All of a), b) and c) should no
> > > longer be problematic in this case. I found that on Debian and
> > > Gentoo Linux this is already the case. To make this work a
> > > udev rule needs to be packaged that passes ownership of /dev/tpm0
> > > device to the tss user. To prevent regressions when switching
> > > from the privilege drop approach to this new approach, a possibly
> > > already existing /var/lib/tpm/system.auth file needs to be safely
> > > chown()'ed to the tss user during package updates.
> > >
> >
> > On Fedora and RHEL there currently is a udev rule (from upstream)
> > that ships with the tpm2-tss package that is setting ownership of
> > /dev/tpm0 to tss:root. I don't recall what the reasoning was for
> > the group being root. For /dev/tpmrm0 it sets it to tss:tss, so not
> > sure what the reason was for /dev/tpm0. I believe that package is
> > part of a default install, so that will need to be worked out. I
> > don't know if you run into that with SUSE as well.
>
> The idea behind not giving the tss group access to /dev/tpm0 as well
> is to prevent users from gaining direct access to the TPM and being
> able to DoS it. Users privileged to access the TPM should be added to
> the tss group so that they can access the TPM trough an access
> broker/resource manager (like tpm2-abrmd, the in-kernel resource
> manager /dev/tpmrm0, or tcsd in case of TPM 1.2), but not have "bare
> metal" access, which is limited to the tss user and root. See [1] for
> reference.
That may be a bit of a misconception about how tpmrm operates. It's
simply the in-kernel resource manager which virtualizes the transient
objects and the session handles (as far as the latter can be
virtualized), so users making contact with the TPM over the tpmrm
device can't interfere with each other (very necessary with TPM 2.0
because it only has room for 3 transient keys). However, a user with
tpmrm access can still DoS the TPM by making it derive RSA keys, for
instance. Plus they can still access the full range of TPM privileged
commands if they have the authorizations. There was talk of adding a
command restriction filter to tpmrm, but it's very hard to do reliably,
which is why it's not been done.
Basically TPM should be treated as a single owner resource, but that
single owner still needs help: I use my TPM for keys for ssh, gpg,
openvpn, secure boot and my general CA infrastructure. Since those
applications operate independently, they could stack enough transient
objects into the TPM to give me an out of memory error unless I go via
the tpmrm device.
James
Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
