YUM security issues...

[Matt_Domsch at Dell.com]

Fedora 7 definitely behaves differently than Fedora 8 and 9.  The
behavior I describe began with F8.  For F7 and earlier, the yum policy
would chose any random mirror from the returned list, so having many
mirrors on the list, some of which are unreachable from inside an
organization, would be bad.  The yum default policy was changed to treat
the mirrorlist as a priority list, so MM returns a longer list.


--
Matt Domsch
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux


-----Original Message-----
From: Justin Samuel [mailto:jsamuel.cs.arizona.edu at gmail.com] On Behalf
Of Justin Samuel
Sent: Friday, July 25, 2008 1:36 PM
To: Domsch, Matt
Cc: Josh Bressers; Mike McGrath; fedora-infrastructure-list at redhat.com;
Justin Cappos; security at fedoraproject.org
Subject: Re: YUM security issues...

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

Matt Domsch wrote:
> On Fri, Jul 25, 2008 at 12:46:15PM -0400, Josh Bressers wrote:
>> On 25 July 2008, Matt Domsch wrote:
>>> Yes, this is a known challenge with subnet delegation in
>>> MirrorManager.  We're trusting package signing (and soon, repodata
>>> signing) to prevent rogue mirrors from issuing unsigned data.  In
>>> addition, I'm working on adding in a way to prevent stale mirrors
>>> (with signed content) from being used.
>>>
>> How does one get this subnet delegation though?  Can I request any
subnet I
>> want, or do we do some sort of verification?
> 
> At present there is no verification (I'm not at all sure how one
> _could_ verify except by ARIN & co  delegation).  However there are
> limits as to how large a block can be requested.  Nothing larger than
> a IPv4 /16 can be automatically requested.  Fedora Infrastructure
> admins can add larger blocks, and request ARIN & co data when doing
so.
> 
> 
>> What happens if the client decided its mirror is bad, I presume it
will go
>> off and find a better one, even with delegation?
> 
> Yes, the mirrorlist returned includes quite a few mirrors, in priority
order.

Our testing showed that when our client was in a MirrorManager-defined
CIDR block for a mirror, the returned mirrorlist included only the
single mirror. -- It's dangerous either way, of course, but I'm just
wondering if our testing was faulty, if this has changed since we
tested, or if it might be behaving differently than you expect.

Possibly you tested with a block that was already defined by other
mirrors and so multiple entries were returned in the mirrorist? That's
just a guess, we didn't test with a block that was defined by more than
one mirror (as far as we knew, at least).

- --
Justin Samuel
https://www.cs.arizona.edu/~jsamuel/
gpg: 0xDDF1F3EE [66EF 84E2 F184 B140 712B 55A7 2B96 AB8F DDF1 F3EE]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIih0cK5arj93x8+4RAklWAKC+Lewfd+pixUvL2MvbdCYxnjHBpQCdHtNd
x5BQsM6GqW5zKpJt+RH8Vco=
=w9yV
-----END PGP SIGNATURE-----