antoine at nagafix
Nov 8, 2004, 12:08 PM
Post #18 of 33
(1205 views)
Permalink
|
Hi all,
I don't mean to join the ego fight, but I do think there are some good
points worth discussing here.
On Mon, 2004-11-08 at 17:14 +0100, Thierry Carrez wrote:
> Peter Simons wrote:
>
> > So why is the Gentoo team so incredibly reluctant to do
> > anything about it?
>
> I don't like your style, but I think I can get your point. The current
> system update setup is vulnerable to man in the middle attacks between
> the master rsync server and the end user. And you think there is an easy
> solution that can be set up really quickly that will mitigate that risk.
> So you're not happy because you don't get why we don't already include
> your solution.
My understanding is that Peter would prefer any solution to not having
one at all...
> First, please note that hose attacks are not that easy to perform and
> that you probably have a lot to worry about if you have someone
> malicious controlling all network flow and DNS information to your
> machines. Saying this doesn't mean I am ignoring the risk you talk
> about. I'm just putting it in perspective.
Sure, but I would argue that malicious upstrean servers are potentially
not that uncommon. Think of all the cyber-cafes, workplaces where too
many people have root access to critical machines, etc.
It would have to be a fairly well targeted approach, but the threat
exists nonetheless.
> Second, "the Gentoo team" is not one person sitting in the dark and
> saying "No, you're wrong, period.". It's a large group of volunteers,
> and you'll find some of them (mostly security guys) have been battling
> for years to get a good and secure update mechanism in Gentoo. For some
> of them, security is highest prio, for others it's stability, for others
> it's performance, etc. That's why things are going on slowly. And
> frankly, we're way better now than we were a year ago.
>
> Now on to your solution. As the funny guy with the beard says, security
> is a trade-off, it's not a binary status. We are not "unsecure" now and
> we'll not be "secure" with your solution applied. The risk here is that
> someone controlling your network flow and/or poisoning Gentoo DNS
> information can execute code with root privileges on any machine doing
> sync and updates. Your solution mitigates that risk by securing the link
> between the master rsync server and the end user using a signed digest
> that is controlled at the end user level using a key downloaded by other
> supposedly secure means, and kept updated by other supposedly secure
> mechanism.
Point taken, there is still a danger here, always will be somewhere.
> This does not mitigate the (supposed lower) risk of having the main
> rsync mirror compromised, the Gentoo CVS tree poisoned by unauthorized
> users, or getting a corrupted master public key from your
> man-in-the-middle controlling-all-network-flow bad guy.
Yes, but the important point is that you only need to get safe access to
the key *once* (possibly for all your systems). After that, no
man-in-the-middle can ever get in the way.
> This is not the ultimate solution but one which has the merit of being
> simple (from your point of view) to be set up and that secures a part of
> the chain that you feel is the easiest to corrupt. So it's a band-aid,
> waiting for something more serious (all tree file signing with
> individual dev keys) to get ready. We'll let the concern of whether
> applying such a solution will or will not slow down the set up of the
> real one true good but too-slowly-coming security mechanism to others.
Anything is better than nothing, I admit it would be a shame if it
slowed down other initiatives, but again, tough.
> What are the trade-offs you forget because of your agenda ? I can think
> of two, and being a security-oriented person, I suppose others with a
> different agenda will find more.
>
> First, this added security layer will mean that for all users (including
> those who don't care) the speed of availability of software through
> portage will be a bit lower. We'll have to sync rsync with CVS,
> calculate the digest and sign it before having it replicated with the
> second-order mirrors. How much time does it take to generate MD5 (+
> probably SHA1 I suppose) of every file in portage ? I would like to
> know. Some users might complain that the added security they don't care
> about because they don't think MiM attacks likely on their systems will
> slow software availability. Who cares it takes an extra 30 minutes ?
> Tell that to those who sync 4 times per hour.
Make it optional, as mentioned in another thread, it doesn't take very
long to generate sigs.
> OK, next, the end user side. You'll have to hook up tree signature
> verification to portage directly, as portage somehow executes code it
> fetched from the network when updating metadata and performing profile
> updates. We have a very large bunch of users (obviously not on this
> mailing list) complaining that emerge sync is waaaay too slow. How much
> time does it take to do MD5+SHA1 verification of every single file in
> /usr/portage after the rsync is complete ? That also I would like to
> know. That would help evaluate the real tradeoffs your solution implies.
> An optional FEATURE ? Letting the no-clue users out of protection is not
> nice, but I suppose it's needed by your solution.
Not needed, just an optional layer of protection.
IMHO, users who don't understand why they would need this feature have
more important things to worry about.
> Last, your simple solution means work for the infrastructure team (to
> change the rsync replication process, provide for CPU time to perform
> the digest etc... And the portage team (testing and releasing extra
> functionality controlled by a FEATURE most people won't activate because
> it slows down the emerge sync process). Rephrasing your proposal as :
>
> (1) infrastructure scripts to generate signed digest
> (2) portage patches including the FEATURE of glocal verification
> (3) hard data showing the performance hit server-side and client-side
>
> would certainly help us. It's not your job to do an implementation
> proposal ? That's the "Gentoo team" job ? Man, get real. Gentoo is a
> community distribution. The "Gentoo team" cannot do everything, it needs
> user support. And yes, even posting a small script helps.
I think anyone on this list is capable of writing the shell scripts
needed to generate the sigs, but fewer truly understand how that would
integrate with the gentoo servers, mirrors and portage. I certainly
don't!
my 2c, please don't flame - there is a high probability I am wrong.
Antoine
--
gentoo-security [at] gentoo mailing list
|
signature.asc
1
