FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 06-22-2011, 08:57 PM
Camilo Mesias
 
Default Trusted Boot in Fedora

I'm curious to know the use case(s) for this technology.

Does it enable certain types of behaviour that aren't possible currently?

Would it enable a system running Fedora to interact with other systems
with a greater guarantee about its behaviour or function?

Is it just something that system integrators would see as a feature
enabling them to make a secured system (ie something useful for RHEL)?

If it just allows you to optionally run a signed kernel, I don't
understand the point if it can be circumvented by choosing to run an
unsigned one. So I think there must be some benefit that isn't
obvious. What's the benefit?

-Cam
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 06-22-2011, 09:32 PM
Daniel J Walsh
 
Default Trusted Boot in Fedora

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/22/2011 04:57 PM, Camilo Mesias wrote:
> I'm curious to know the use case(s) for this technology.
>
> Does it enable certain types of behaviour that aren't possible currently?
>
> Would it enable a system running Fedora to interact with other systems
> with a greater guarantee about its behaviour or function?
>
> Is it just something that system integrators would see as a feature
> enabling them to make a secured system (ie something useful for RHEL)?
>
> If it just allows you to optionally run a signed kernel, I don't
> understand the point if it can be circumvented by choosing to run an
> unsigned one. So I think there must be some benefit that isn't
> obvious. What's the benefit?
>
> -Cam
The idea is to allow certain tools/machines to make judgments on how
"trusted" a machine is. For example you could set up a VPN server that
says I will only allow a machine that passes the "Trusted" test to join
my network. Another potential example would be to not allow a guest
machine to run on your host if its OS is not "Trusted" Or to have a
guest OS check to see if the Host Server is Trusted or stop running.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk4CX4IACgkQrlYvE4MpobPJ6QCg4Rx6gj1XlC ObyFV920kgs3bN
tQUAn0B50VPRjMb8cIv42GktSA/UxFgD
=JaeC
-----END PGP SIGNATURE-----
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 06-23-2011, 12:02 AM
James Morris
 
Default Trusted Boot in Fedora

On Wed, 22 Jun 2011, Simo Sorce wrote:

> > If so, is there a mechanism to disable that functionality, or mark a
> > kernel as trusted, so that I could, for example, run a kernel I built
> > myself or one from another RPM?
>
> I would say that if this feature prevents users from creating their own
> trusted kernels we shouldn't probably care supporting it.

After digging through the sparse documentation, it seems the lcptools
package is how you would do this, although it's not really clear at all.
The LCP user tools manual was last updated in 2007.

The tboot package doesn't seem to have been updated since 2010.

Is this being actively maintained?


- James
--
James Morris
<jmorris@namei.org>
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 06-23-2011, 01:55 AM
Eric Paris
 
Default Trusted Boot in Fedora

On 06/22/2011 03:02 PM, Matthew Garrett wrote:
> http://fedoraproject.org/wiki/Features/Trusted_Boot is a proposed
> feature for F16. We've traditionally had a hard objection to the
> functionality because it required either the distribution or downloading
> of binary code that ran on the host CPU, but it seems that there'll
> shortly be systems that incorporate the appropriate sinit blob in their
> BIOS, which is a boundary we've traditionally been fine with.

Such systems supposedly exist today. I haven't tested them, but I
believe a number of the newer Dell systems already have the required
northbridge code in flash. tboot will use the binary northbridge setup
blob that may be passed to it or it will try to use any blobs built into
the flash if it isn't given a blob by grub. In the case that it doesn't
have the magic blob needed to set up the CPU and northbridge it just
won't execute the magic SENTER instruction. magic!

> However, this is the kind of feature that has a pretty significant
> impact on the distribution as a whole.

I actually think this is completely wrong. It shouldn't have ANY distro
wide impact at all.

> Fesco decided that we should
> probably have a broader discussion about the topic. The most obvious
> issues are finding a sensible way to incorporate this into Anaconda, but
> it's also then necessary to make sure that bootloader configuration is
> updated appropriately.

Agreed. These are exactly the parts that they need to do development.
Anaconda shouldn't really need changes, tboot is just a package that
needs installed. I'm not sure why that's even a part of the feature
request. If anaconda creates the initial grub.conf it might need some
work but that is the same issue as the next question. Grubby is what
needs discussion and new code. It will need to detect tboot is
installed and handle new grub type entries correctly. I haven't seen
any code for this, but handling new formats of grub entries is what is
really needed here.

> Outside that, is there any other impact?

There shouldn't be. Mind you if you want this to be useful for
something it's going to take more steps and layers on top, but just
booting into a measured launch environment should require no other steps.

> Does tboot perform any
> verification of the kernels, and if so how is that configured?

tboot does no such thing. By default tboot and the Intel Trusted
Execution Technology do nothing but measure and record information in a
reliable, immutable, verifiable way. If one were to create and install
a launch control policy into their own TPM (using the lcp tools) then
that policy would be enforced at boot. But this is not and should not
be a part of this feature request. The TPM key management required to
update the lcp on kernel update just doesn't exist today in a practical
way. Instead what we get from this is that tboot will 'measure', aka
take a cryptographic hash of the kernel and initrd, and put those into
the TPM before it launches the kernel. Thus after the kernel starts
there is a method to verify that the hardware was in a known safe state
and to verify what the kernel's hash was at launched.

> Is the
> expectation that an install configured with TXT will only boot trusted
> kernels,

NO NO NO NO NO. ANY mechanism that prevents users from using their own
system will require MANUAL intervention on the part of the user. It's
possible to build such a box yourself, but If such a change is ever
suggested it should (and will be immediately by me) rejected.

> and if so what mechanism is used to verify the kernel?

tboot + the Intel Trusted Execution Technology hardware are what's used
to measure and launch the kernel. If a launch control policy is
configured it will be used to decide if such a kernel should be
launched. But there is NO way we should (or even could) EVER
automatically create an lcp.

> Is there
> any further integration work that has to be performed for this to be
> useful?

So much you cannot imagine At the moment they are just try to get a
system which is capable of measuring itself. We already have kernel
functionality which can measure any files being accessed, but we have no
way to know what kernel was launched? What good is a list of files if
you can't trust the guy creating that list? This gets us that last
step, we have a way to know the state of the system and the
cryptographic hash representing the contents of the kernel (and initrd)
which was launched. We don't have a way to USE this data. Red Hat has
some long term goals on how to use this functionality in the enterprise
and the gov't has some ideas how to use it in their super secret
intelligence world.

Nothing about this should be a default. Nothing about this should
affect users who don't turn it on. Nothing about this should lock
people out of their own computers.

Does this help?

-Eric
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 06-23-2011, 01:57 AM
Eric Paris
 
Default Trusted Boot in Fedora

On 06/22/2011 03:01 PM, Jon Ciesla wrote:
>

>> Outside that, is there any other impact? Does tboot perform any
>> verification of the kernels, and if so how is that configured? Is the
>> expectation that an install configured with TXT will only boot trusted
>> kernels, and if so what mechanism is used to verify the kernel? Is there
>> any further integration work that has to be performed for this to be
>> useful?
>
> If so, is there a mechanism to disable that functionality, or mark a
> kernel as trusted, so that I could, for example, run a kernel I built
> myself or one from another RPM?

By default this would not be enabled. And even if so, out of the box
the only thing it will ever do it measure the kernel you built and store
that info. You would be able to create your own lcp which only allowed
whatever kernels you wished, but that's a whole different issue than
what is being asked for here.

-Eric
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 06-23-2011, 02:05 AM
Eric Paris
 
Default Trusted Boot in Fedora

On 06/22/2011 03:20 PM, seth vidal wrote:
> On Wed, 2011-06-22 at 20:02 +0100, Matthew Garrett wrote:

> Are we going to continue the double grub entries? while I realize that
> tboot SHOULD allow non TXT hw to boot properly I also realize that any
> differences will be pointed to as a point of contention when debugging
> semirelated problems. so it seems like the double entries are wise.
>
> Additionally, is the grub modifyication implemented in grubby and does
> this behave properly on a yum update of the kernel?

I'd say how to handle the grub entries is basically the entire point of
the feature request. I was surprised to learn the other day that they
filed a request at all since this was really just about making a change
to grubby. I don't know how they plan to handle it.

Systems which don't support TXT are easy. They will work fine. The CPU
won't say it supports TXT and tboot will just move along.

The real problem is systems which claim to support TXT, but then don't.
tboot is actually really smart and will record that it tried a TXT
enabled boot and if it fails will not use the TXT instructions the next
time (this happens on things like the Lenovo x201). On other platforms,
like the Lenovo x210 TXT does something when setting the iommu's in a
safe state which causes the video card to go haywire when it tries to
get set up. Now tboot can't tell this, since TXT completed and the
kernel did actually launch successfully, but I'd imagine half ass broken
hardware won't be common for too long. Intel had a kernel patch they
thought would fix the problem, but I lost access to the system in
question before I could test it (and I don't know if it was sent upstream)

Systems which ACTUALLY support TXT are easy. They just work and you
don't even know your kernel was measured and and the iommus programmed
to be safe before it launched.

So yeah, installing tboot if it automatically enables itself can be a
problem on some broken hardware. I would certainly recommend against
making tboot a part of the default install. But if a user installs it,
it should 'just work', without manually updating grub on ever kernel update.

-Eric
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 06-23-2011, 07:52 AM
Tomas Mraz
 
Default Trusted Boot in Fedora

On Wed, 2011-06-22 at 21:55 -0400, Eric Paris wrote:
> On 06/22/2011 03:02 PM, Matthew Garrett wrote:
> > http://fedoraproject.org/wiki/Features/Trusted_Boot is a proposed
> > feature for F16. We've traditionally had a hard objection to the
> > functionality because it required either the distribution or downloading
> > of binary code that ran on the host CPU, but it seems that there'll
> > shortly be systems that incorporate the appropriate sinit blob in their
> > BIOS, which is a boundary we've traditionally been fine with.
>
> Such systems supposedly exist today. I haven't tested them, but I
> believe a number of the newer Dell systems already have the required
> northbridge code in flash. tboot will use the binary northbridge setup
> blob that may be passed to it or it will try to use any blobs built into
> the flash if it isn't given a blob by grub. In the case that it doesn't
> have the magic blob needed to set up the CPU and northbridge it just
> won't execute the magic SENTER instruction. magic!
>
> > However, this is the kind of feature that has a pretty significant
> > impact on the distribution as a whole.
>
> I actually think this is completely wrong. It shouldn't have ANY distro
> wide impact at all.
>
> > Fesco decided that we should
> > probably have a broader discussion about the topic. The most obvious
> > issues are finding a sensible way to incorporate this into Anaconda, but
> > it's also then necessary to make sure that bootloader configuration is
> > updated appropriately.
>
> Agreed. These are exactly the parts that they need to do development.
> Anaconda shouldn't really need changes, tboot is just a package that
> needs installed. I'm not sure why that's even a part of the feature
> request. If anaconda creates the initial grub.conf it might need some
> work but that is the same issue as the next question. Grubby is what
> needs discussion and new code. It will need to detect tboot is
> installed and handle new grub type entries correctly. I haven't seen
> any code for this, but handling new formats of grub entries is what is
> really needed here.
>
> > Outside that, is there any other impact?
>
> There shouldn't be. Mind you if you want this to be useful for
> something it's going to take more steps and layers on top, but just
> booting into a measured launch environment should require no other steps.

So to recap this for the next FESCo meeting(s).

1. There exists hardware that does not require any binary blobs to be
downloaded or distributed within Fedora.
2. The feature does not have any substantial negative impact on the rest
of the distribution (apart from requiring some integration work from
grubby and anaconda maintainers).
3. What's really missing is the agreement between tboot, anaconda, and
grubby maintainers on how to integrate the trusted boot into grubby and
anaconda.

Is that correct?

--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 06-23-2011, 11:58 AM
"Jon Ciesla"
 
Default Trusted Boot in Fedora

> On 06/22/2011 03:01 PM, Jon Ciesla wrote:
>>
>
>>> Outside that, is there any other impact? Does tboot perform any
>>> verification of the kernels, and if so how is that configured? Is the
>>> expectation that an install configured with TXT will only boot trusted
>>> kernels, and if so what mechanism is used to verify the kernel? Is
>>> there
>>> any further integration work that has to be performed for this to be
>>> useful?
>>
>> If so, is there a mechanism to disable that functionality, or mark a
>> kernel as trusted, so that I could, for example, run a kernel I built
>> myself or one from another RPM?
>
> By default this would not be enabled. And even if so, out of the box
> the only thing it will ever do it measure the kernel you built and store
> that info. You would be able to create your own lcp which only allowed
> whatever kernels you wished, but that's a whole different issue than
> what is being asked for here.
>

Ok. What information is stored where and how?

-J

> -Eric
>


--
in your fear, seek only peace
in your fear, seek only love

-d. bowie

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 06-23-2011, 02:21 PM
JB
 
Default Trusted Boot in Fedora

Matthew Garrett <mjg59 <at> srcf.ucam.org> writes:

> ...
> http://fedoraproject.org/wiki/Features/Trusted_Boot is a proposed
> feature for F16.
> ...

Hi,

there will be some posts on Fedora users and testers lists, so please take
a look.

http://lists.fedoraproject.org/pipermail/users/2011-June/400539.html

http://lists.fedoraproject.org/pipermail/test/2011-June/100976.html

In the meantime, I got access to this mailing list, so all is well :-)

I have done some inventory on this topic, and have some questions.

The Intel Trusted Platform consists of two components:
- Trusted Platform Module (TPM) chip
A hardware component, consisting of cryptographic processor and secure
memory.
- Trusted Boot
A software component, open-source and partially close-source (?) components,
in Fedora packages.
# yum install tboot
Installing:
tboot i686 20110429-1.fc15 fedora 355 k
Installing for dependencies:
trousers i686 0.3.6-1.fc15 fedora 279 k

Trusted Boot is a mechanism by which a pre-kernel/VMM module (that uses Intel
Trusted Execution Technology (Intel TXT)) performs a measured (pre-identified)
and verified launch of an OS kernel/VMM.

First, the obvious questions.

Why do you need Trusted Boot mechanism to ensure that identified and origin-
verified Linux kernel is booted ?
Why signing a kernel (a la GPG) is not good enough to verify its origin at
boot time ?

Now, regarding the Trusted Boot solution.

The obvious question:
why does an open-source distro like Fedora (but also Red Hat) want to
philosophically accept and technically support this solution ?

Will the TPM allow a third party remote access to the machine ?

Will the TPM be BIOS-configurable (enable/disable) by the user (hardware
owner) ?
If so, how will that impact the kernel selection in boot process (tboot
enable/disable) ?

How is that tboot blob module secured from tampering ?
By the virtue of beeing associated with the "root of trust" ?

If the Launch Control Policy can be created and modified by the user, then
what prevents an attacker from impersonating the usersysadmin, modifying
the policy, and causing a denial-of-boot or unintended-boot attack ?

There is more that this project implements (root of trust, etc).

Ref: tcsd(8)
Can that "root of trust" be compromised by TSS applications or any other
means (e.g. through tools provided by this project) ?

...
Ref: tcsd(8)
DEVICE DRIVERS
tcsd is compatible with the IBM Research TPM device driver available
from http://www.research.ibm.com/gsal/tcpa and the TPM device driver
available from http://sf.net/projects/tmpdd

Are these drivers open-source ? Is TPM device driver open-source ?

JB


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 06-23-2011, 02:21 PM
JB
 
Default Trusted Boot in Fedora

Matthew Garrett <mjg59 <at> srcf.ucam.org> writes:

> ...
> http://fedoraproject.org/wiki/Features/Trusted_Boot is a proposed
> feature for F16.
> ...

Hi,

there will be some posts on Fedora users and testers lists, so please take
a look.

http://lists.fedoraproject.org/pipermail/users/2011-June/400539.html

http://lists.fedoraproject.org/pipermail/test/2011-June/100976.html

In the meantime, I got access to this mailing list, so all is well :-)

I have done some inventory on this topic, and have some questions.

The Intel Trusted Platform consists of two components:
- Trusted Platform Module (TPM) chip
A hardware component, consisting of cryptographic processor and secure
memory.
- Trusted Boot
A software component, open-source and partially close-source (?) components,
in Fedora packages.
# yum install tboot
Installing:
tboot i686 20110429-1.fc15 fedora 355 k
Installing for dependencies:
trousers i686 0.3.6-1.fc15 fedora 279 k

Trusted Boot is a mechanism by which a pre-kernel/VMM module (that uses Intel
Trusted Execution Technology (Intel TXT)) performs a measured (pre-identified)
and verified launch of an OS kernel/VMM.

First, the obvious questions.

Why do you need Trusted Boot mechanism to ensure that identified and origin-
verified Linux kernel is booted ?
Why signing a kernel (a la GPG) is not good enough to verify its origin at
boot time ?

Now, regarding the Trusted Boot solution.

The obvious question:
why does an open-source distro like Fedora (but also Red Hat) want to
philosophically accept and technically support this solution ?

Will the TPM allow a third party remote access to the machine ?

Will the TPM be BIOS-configurable (enable/disable) by the user (hardware
owner) ?
If so, how will that impact the kernel selection in boot process (tboot
enable/disable) ?

How is that tboot blob module secured from tampering ?
By the virtue of beeing associated with the "root of trust" ?

If the Launch Control Policy can be created and modified by the user, then
what prevents an attacker from impersonating the usersysadmin, modifying
the policy, and causing a denial-of-boot or unintended-boot attack ?

There is more that this project implements (root of trust, etc).

Ref: tcsd(8)
Can that "root of trust" be compromised by TSS applications or any other
means (e.g. through tools provided by this project) ?

...
Ref: tcsd(8)
DEVICE DRIVERS
tcsd is compatible with the IBM Research TPM device driver available
from http://www.research.ibm.com/gsal/tcpa and the TPM device driver
available from http://sf.net/projects/tmpdd

Are these drivers open-source ? Is TPM device driver open-source ?

JB


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 09:35 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org