From: "Anders Karlsson" <anders@xxxxxxxxxxxxxx>
Sent: Friday, 2008, September 05 13:12
* jdow <jdow@xxxxxxxxxxxxx> [20080905 20:52]:
From: "Anders Karlsson" <anders@xxxxxxxxxxxxxx>
Sent: Friday, 2008, September 05 00:50
* jdow <jdow@xxxxxxxxxxxxx> [20080905 08:56]:
Suppose I have NO RedHat installed. I have no working computer near
me. I want to install Fedora 9. How do I establish the ability to
subject the packages to tests for being properly signed, that the
key used in the test is correct, and that I am reading and updating
from a legitimate mirror?
In this event you are likely installing from physical media, which
will have the public key on it already. If you do not trust that media
- why are you installing from it?
Where did I get the media? How do I establish the chain of trust?
Perhaps I downloaded with an old copy of Red Hat 4.0 I had laying
around. If trust can be established from zero then it can happen
again.
You had no OS installed - so where did you get the media from?
The only thing that matters at this point is whether you do, or not,
trust the media you are installing from? If you do - then you will
have a good key on the media that will validate updates later.
I probably should have said no OS new enough to have been signed. That
is why I amplified it to the old copy of RH4 or maybe a really antique
Slackware. The idea is that I had something via which I could initialize
the bootstrap process - barely.
Basically I had to trust that when I logged into download.fedora...
that I went to the right place and nobody in the middle was in a
position to futz the results. If I was paranoid I could then go to
several of the other mirror sites and perform downloads of at least
the signatures to see if they were bit copies of each other.
I could, with enough work, establish trust. I can, if needed, do that
again. Poof - much discussion about nothing new. It's all old well
covered territory.
Once you have installed the system - the updates you are pulling down
will be verified with the key that was on the media - unless you
actively go and switch off the gpg checking.
If I am actually going to the right mirrors and not a setup of fast
flux servers full of malware that will be true.
Mu.
The Fedora installation media installs repo configs that point to the
Fedora projects servers. Your comment indicates that you believe your
ISP and the DNS servers you use are compromised. At this point - all
bets are off.
As others have already pointed out - it's a question of trust. At some
point or other - you have to decide what you trust. If you do not
trust something, do not use it (and then live with the consequences of
that choice).
Exactly. This is the point. If I can proceed from zero and establish
trust once I can do it again. So I am unclear over what the problem
in that regard can be such that it would stall the process of getting
rolling again.
I can see other items causing a hitch in the gitalong. But I cannot
see any means other than trusting my DNS server and the routers
between download.fedora.redhat.com and me. If I could trust them once
I can trust them again. So the focus of this thread is wrong. It
should be more along the lines of "How can a company that uses RPM
and signed packages arrange to have the packages multiply signed so
that both an old obsolete key works and a new key works?"
THAT is probably not a simple problem. I also suspect it is not something
considered in designing rpm itself or the distribution system.
This is what the infrastructure team have been working on, and reading
the fedora-devel list should give answers to the plans that they have.
It would appear that you can only sign a package with a single key at
a time. I just tested it.
Of course, if you think about it an RPM that will accept multiple
signatures would also have to have a proper signature revocation protocol
involved. But how does that prevent someone who has compromised the
key from issueing a revoke and a new key that is next used to sign a
full set of forged RPMs? I imagine the Fedora and Red Hat fellows have
their hands seriously full figuring out how they are going to handle
the whole process.
[snip]
If trust can be established once, it can be establised again the same way
as many times as needed. So the discussion needs to move to what may be
the REAL problem. Can an rpm be signed with multiple keys in any
meaningful way so that people pre-update can still grab the key updates
and compare files prior to a specific date against the old key while new
files compare against the new key.
It appears the answer is no. Only one signature at a time. This is one
of the problems the infrastructure team have been wrestling with.
If THAT can be done it seems like both this discussion and the delay
are somewhat spurious, right?
It would appear the discussion is not entirely spurious. ;-)
Large chunks of the discussion have bypassed the main problems in flights
of trust fantasy. They established trust once. They can do it again. So
that is not the problem other from a convenience standpoint.
Nor is RPM accepting multiple keys the real problem, necessarily. It will
accept multiple keys already - one at a time. It becomes the users PITA
to figure out which one to use on a package. But in the "Establish Trust"
world that's always been the problem; and, it's been solved. Do it once
means you can do it repeatedly.
Mike recounted his original issues. One of them touched what I see as the
really big issue.
M> Since Fedora got compromised, we'd like to know
M> what they run on their servers, and whether we
M> might ourselves be vulnerable to the same kind of
M> attack which compromised Fedora in the first place.
M> If so, we'd like to know what the attack was,
M> how it succeeded, and how to protect against it.
Red Hat and Fedora both push SELinux heavily. As I remember my older
days in the DoD world and articles I have read over the years major
components of SELinux include access control lists and logs. The ACL as
a tool prevents unauthorized access to files even by "root". And logs
are supposed to be rigorous enough to track the movements of any account
on the machine such that you can tell if the machine was compromised and
how it was compromised. If the machines were compromised such that the
log files are insecure that must have the NSA folks in a really serious
tizzy if SELinux was installed and used properly.
(If I was in that environment, I'd have a separate logging machine that
had no means if ingress and performed logging via "tail -f" on the real
log files over ssh connections from the log check machine. This is a
variant of the old log to TTY machine process of the bad old days.)
For one I'd like to know if they used their own Bandini (tm) known as
SELinux. And I'd like to know how they were compromised. (And I bet
they would, too.)
{^_^} Joanne
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
