# emerge sync security

## Kruegi

I have a security related question:

Is there any way to be sure I'm syncing my portage tree with a Gentoo-Server and not with a faked server? Without any security like HTTPS or signatures a Man In The Middle would be able to send me a modified portage tree.

Kruegi

----------

## adaptr

 *Kruegi wrote:*   

> Without any security like HTTPS or signatures a Man In The Middle would be able to send me a modified portage tree.

 

Of course not - as long as you can trust your nameservers then you will be connected to the right server.

Anyone who can spoof IP addresses on your route path will be able to do much worse to you than just provide a fake rsync server.

The only parties that could conceivably even try this are your ISP or a backbone carrier in between your ISP and the Gentoo server.

Believe me - they won't bother.

----------

## Kruegi

So there are no signatures, no certificates or similar security method. In this case I have to consider Portage as insecure. 

I'm actually planning to set up a highly secured server with Gentoo. Without a trustable method of syncronizing the Portage tree it makes no sense.

Are there any plans or discussions to implement security to Portage updates? Maybe rsync via SSH could give some security. At least there are machine keys and encryption. On the other hand it will cause high load on the servers.

Thomas

----------

## adaptr

A very simple solution is to compile all binary packages on another system and manually merge them on the secure server.

This way you will always have complete control over the process.

Or you could keep 2 or 3 portage trees separate and sync each from a different server; then only accept a package when all three are identical.

I wouldn't let an important server auto-update anything anyway.

And the trustability of the rsync server is not that important anyway - it's the source packages you have to be able to trust.

But let me ask you this simple question: How often, in your experience, have your ISP's control center, your company's intranet, or indeed your hotmail account been compromised in this way ?

It's a lot less likely than you make it out to be.

----------

## Naib

dont portage tree snapshots have md5 checksum with them?

you cant just emerge sync with these, you have to d/l a tarball

--edit--

yes they do

ftp://ftp.mirrorservice.org/sites/www.ibiblio.org/gentoo/snapshots/

this is a UK mirror but as you can see...

----------

## Kruegi

 *adaptr wrote:*   

> A very simple solution is to compile all binary packages on another system and manually merge them on the secure server.
> 
> This way you will always have complete control over the process.

 

This would minimize the risk. As long as my connection is secure...

 *adaptr wrote:*   

> Or you could keep 2 or 3 portage trees separate and sync each from a different server; then only accept a package when all three are identical.

 

That may give a lot of trouble.

1. It's not much harder to fake 3 server if you are able to fake one.

2. The portage tree changes very quickly and it may be a problem to get 3 indentical versions.

 *adaptr wrote:*   

> I wouldn't let an important server auto-update anything anyway.

 

I will surely not put "emerge -uD world" into my crontab...  :Wink: 

 *adaptr wrote:*   

> And the trustability of the rsync server is not that important anyway - it's the source packages you have to be able to trust.

 

You are right, but that's an other chapter in the book of security. At least the MD5 digest in Portage can identify faked packages.

 *adaptr wrote:*   

> But let me ask you this simple question: How often, in your experience, have your ISP's control center, your company's intranet, or indeed your hotmail account been compromised in this way ?

 

The server should be placed in a 3rd party computing center for hosting. While I have (limited) trust to the hoster and there ISPs, I can't trust the other customers who have servers in the same subnet. 

Kruegi

----------

## Kruegi

 *Naib wrote:*   

> dont portage tree snapshots have md5 checksum with them?
> 
> you cant just emerge sync with these, you have to d/l a tarball
> 
> --edit--
> ...

 

A simple MD5 sum does not help. I can also be faked, especially it it comes from the same source.

But there are also GPG signatures. They may be the thing I was looking for.

Kruegi

----------

## adaptr

 *Quote:*   

> 1. It's not much harder to fake 3 server if you are able to fake one. 

 

Prove it.

Faking one servers' DNS entries or IP address needs control over a nameserver at least; a compromised host on its routing path at most.

Faking two will by definition require twice as much resources.

 *Quote:*   

> You are right, but that's an other chapter in the book of security. At least the MD5 digest in Portage can identify faked packages. 

 

Of course not - if they can corrupt the packages then they can screw the MD5sums...

It would, by the way, be trivial - once you have such a compromised system set up - to change the ebuilds completely.

After that, the integrity of the source packages doesn't matter in the least...

 *Quote:*   

> The server should be placed in a 3rd party computing center for hosting. While I have (limited) trust to the hoster and there ISPs, I can't trust the other customers who have servers in the same subnet. 

 

This makes no sense - systems on the same subnet as your server will by definition never be a part of its routing path.

Ever.

So spoofing can't be done from those systems.

----------

## Kruegi

There is no need of beeing in the routing path or having control over the names server. The routing path can be altered by ARP poisoning and DNS queries are UDP and can be manipulated.

Even script kiddies can do so. There are easy to use tool like Cain & Abel. Even for Windows.

Kruegi

----------

## adaptr

So install iptables; be smart.

Set up a sentry system that continually arpings the subnet; if any MAC appears that is not bound to a subnet IP just drop it.

Or just drop anything from that subnet except the gateway.

----------

## Kruegi

Thank you for your recomendation but I made several case studies for securing a local subnet some time ago and the only one that is really save are managed switches, perventing clients to use wrong MAC addresses.

Even if I get the connection saver I could never have full trust into it.

Would you do online banking without HTTPS and a valid certificate?

And want this server really secure. If it get's compromised money may be lost.

Kruegi

----------

## j-m

OK, with this level of paranoia you should not connect the server to any network at all. You cannot even trust PGP-signed packages in other distributions b/c these may be fake as well. Lock the door, nail the windows, bury your server deep under the floor and put a solid layer of concrete on it. 

 :Rolling Eyes:   :Laughing:   :Twisted Evil: 

----------

## adaptr

 *Kruegi wrote:*   

> Thank you for your recomendation but I made several case studies for securing a local subnet some time ago and the only one that is really save are managed switches, perventing clients to use wrong MAC addresses.

 

There is no such thing as absolute security.

Do you mean case studies about the maximum attainable security, or something rooted in actuality, like a cost/risk analysis of existing secured networks versus the known attempts to break them ?

The latter might be interesting, but the former is useless...

----------

## Kruegi

OK something about the studies I made recently:

The task was the prevention of attacks from the inside. (Most administrators don't even know that more than 3/4 of all attacks on confidential data are coming from inside.)

I was collecting all information about the implementation, needed ressources and knowledge, cost, hardware and possible new risk of every security issue.

To name some of them: attacks on ARP tables, DNS Spoofing, unauthorized wireless devices, DoS Attacks, human factors (e.g. "social engineering")...

You surely understand that I can't publish details about thing I implemented somewhere. But I can give some hints if needed.

Sorry if I'm buggy some people with my security fanatism, but it's just part of my job.

@j-m: Even Bill Gates understood the meaning of IT security. Some days ago he started a new initiative to increase the internet security (again  :Wink:  ). Maybe you should think of security as a need. Especially in business. And security is not just allowing the Windows Updater to install patches automaticly.

Kruegi

----------

## Cinquero

 *Kruegi wrote:*   

> Sorry if I'm buggy some people with my security fanatism, but it's just part of my job.

 

This is no fanatism. it is about trust. And denying to provide a trusted source , which could be set up by just signing the portage tree with some gpg key, that is just idiotic. On the other hand, recommendations to introduce remote management are considered insecure without even going into the details.

----------

## jhmartin

Perhaps the gentoo portage hosts should provide a stunnel-based front for rsync that uses a certificate root that is trusted by portage, and controlled by the Gentoo maintainers. That way only officially blessed portage mirrors get certs, and portage can (optionally) decline to connect to servers that do not have a trusted certificate. This would be hard on the CPU of the portage mirrors though.

----------

## jhmartin

 *Cinquero wrote:*   

> 
> 
> This is no fanatism. it is about trust. And denying to provide a trusted source , which could be set up by just signing the portage tree with some gpg key, that is just idiotic. On the other hand, recommendations to introduce remote management are considered insecure without even going into the details.

 

Signing the entire portage tree would be very time CPU intensive, considering how much it changes.

----------

## Cinquero

 *jhmartin wrote:*   

> Perhaps the gentoo portage hosts should provide a stunnel-based front for rsync that uses a certificate root that is trusted by portage, and controlled by the Gentoo maintainers. That way only officially blessed portage mirrors get certs, and portage can (optionally) decline to connect to servers that do not have a trusted certificate. This would be hard on the CPU of the portage mirrors though.

 

The simplest way is to create signatures for the portage snapshots and to publish the (GnuPG?) public key on a secure site that has its cert signed by a CA recognized by the standard installation of firefox. No CPU problem at all, and the mirrors wouldn't have to adapt.

----------

## jhmartin

 *Cinquero wrote:*   

> 
> 
> The simplest way is to create signatures for the portage snapshots and to publish the (GnuPG?) public key on a secure site that has its cert signed by a CA recognized by the standard installation of firefox. No CPU problem at all, and the mirrors wouldn't have to adapt.

 

How static are portage snapshots? If they change often, then that operation is very time consuming. I agree that GnuPG is the best product for it.  If the packages change often, it would make more sense to have individual ebuilds signed, and have the keyring of authorized signers posted on a reputable site.

I still think it would be a good idea to offer a stunnel+rsync option as well.

----------

## Cinquero

portage snapshots are done once a day. That 30 MB is no problem to sign. It takes half a second on my machine. Signing new ebuild files is even less load, which means: not measurable.

----------

## jhmartin

 *Cinquero wrote:*   

> portage snapshots are done once a day. That 30 MB is no problem to sign. It takes half a second on my machine. Signing new ebuild files is even less load, which means: not measurable.

 

Ooh, I see, I was thinking about signing all of the data, not just the portage tree.  That would be quite a bit smaller. In effect the client would sync the tree, then tar it up in a pipe to gnupg, which would be invoked to compare the results with a detached signature?

----------

## Cinquero

 *jhmartin wrote:*   

> Ooh, I see, I was thinking about signing all of the data, not just the portage tree.  That would be quite a bit smaller. In effect the client would sync the tree, then tar it up in a pipe to gnupg, which would be invoked to compare the results with a detached signature?

 

No. In principle, only the Manifest/digest files need to be signed and verified. On the other hand, one could directly replace the checksums with the signatures. So, instead of running sha1sum etc., portage would run gpg. And I doubt it would make much a difference whether one uses gpg to create signatures or some checksum utility to create checksums.

----------

