# How secure is Gentoo?

## Kasumi_Ninja

Portage provides around 12.000 packages. How well tested are these in regards to exploits and rootkits? Which procedures do the Gentoo devs have in place to ensure maximum security?

----------

## tarpman

http://www.gentoo.org/security/en/index.xml

enjoy.

----------

## Kasumi_Ninja

 *tarpman wrote:*   

> http://www.gentoo.org/security/en/index.xml
> 
> enjoy.

 

Off course I have read Gentoo Linux Security   :Wink: .  Only this leaves some questions open:

-Are all package in the portage stable tree beforehand checked by the security team?

-How does the security team check for malware such as rootkits?

-Is Gentoo (which support 12.000 packages) just as secure as let's say Red Hat and Novell which support far fewer packages?

----------

## tarpman

 *Aniruddha wrote:*   

> -Are all package in the portage stable tree beforehand checked by the security team?

 

No.  Individual package maintainers are generally familiar with the packages they maintain and are responsible for updating Gentoo's packaging (ebuilds and patches) when security problems are discovered, but to the best of my knowledge do not routinely audit third party code.

 *Aniruddha wrote:*   

> -How does the security team check for malware such as rootkits?

 

Package maintainers are responsible for making sure that they are not introducing malicious software into the Portage tree.  To quote the page I linked above, "[t]he Gentoo Linux Security Project is tasked with providing timely information about security vulnerabilities in Gentoo Linux, along with patches to secure those vulnerabilities."  In other words, Gentoo's security team is more about ensuring that vulnerabilities discovered elsewhere have a minimal effect on Gentoo users.

 *Aniruddha wrote:*   

> -Is Gentoo (which support 12.000 packages) just as secure as let's say Red Hat and Novell which support far fewer packages?

 

Without in-depth knowledge of how any of them do their patching/building/auditing, my guess is they're roughly the same.  I've never heard of malicious software being introduced into Portage, and GLSAs are usually issed quite promptly when, for example, new CVEs become available.

Gentoo is very much about choice.  The packages have been made available to you; it's your choice as to which ones to install.  If you are really serious about security, you should be either auditing every line of code that runs on your system personally, or running OpenBSD - or both.

Of course I am in no way an official spokesman for Gentoo, so please don't take anything I say as definite truth.  If you want an official position you should contact the security team (security@gentoo.org) directly with your questions.

----------

## Kasumi_Ninja

Thank you for your extensive explanation. I also  mailed security@gentoo.org to ask for an official statement.

----------

## NeddySeagoon

Aniruddha,

Security is not provided by your distro, regardless of who provides it. Security starts with an attitude of mind.

Its about adding layers, like an onion to your system to make life harder (not impossible) for your attacker, so they go away and find an easier target.

There is an old saying that says (approximately) "the wider you open the window, the more dirt blows in". That means you should not install anything you don't need. Thats one of Gentoos' strong points. You can install a gentoo-hardened system, that adds two layers (or more) to your security onion.

You must start be defining the threat to wish to be secure against. Every distro has random undiscovered problems but hardened makes some types of attack more difficult.

----------

## Carlo

 *Aniruddha wrote:*   

> -Are all package in the portage stable tree beforehand checked by the security team?

 

The security team foremost reacts on vulnerability reports, be it public ones or via restricted channels like e.g. the vendor-sec mailinglist, tracks and assesses them and  writes the GLSAs in the end. Gentoo has not the ressources to examine every single new version of every single package in the repository in depth.

 *Aniruddha wrote:*   

> -Is Gentoo (which support 12.000 packages) just as secure as let's say Red Hat and Novell which support far fewer packages?

 

This is a matter of what you believe, how many ressources these companies (can) spend on such proactive security measures. Just one hint: Check the references in the advisories of the distributors who disclosed the vulnerability.

----------

## Kasumi_Ninja

 *NeddySeagoon wrote:*   

> Aniruddha,
> 
> Security is not provided by your distro, regardless of who provides it. Security starts with an attitude of mind.
> 
> Its about adding layers, like an onion to your system to make life harder (not impossible) for your attacker, so they go away and find an easier target.
> ...

 

Hi Ned,

You have a good point there. If I follow your reasoning this would mean that any distro that requires to add extra repositories for basic functionality (mp3. dvd etc) adds an extra layer and thus becomes more vulnerable then Gentoo which provides all basic functionality in one repository?

----------

## Kasumi_Ninja

 *Aniruddha wrote:*   

> -Is Gentoo (which support 12.000 packages) just as secure as let's say Red Hat and Novell which support far fewer packages?

 

This is a matter of what you believe, how many ressources these companies (can) spend on such proactive security measures. Just one hint: Check the references in the advisories of the distributors who disclosed the vulnerability.[/quote]

What do you mean with "Check the references in the advisories of the distributors who disclosed the vulnerability"

----------

## tarpman

 *Aniruddha wrote:*   

> If I follow your reasoning this would mean that any distro that requires to add extra repositories for basic functionality (mp3. dvd etc) adds an extra layer and thus becomes more vulnerable then Gentoo which provides all basic functionality in one repository?

 

I think he was referring to the security as being layered, rather than the functionality.  Using features such as a hardened kernel and gcc's SSP features adds layers to your security - more layers for any potential hacker to have to get through.  It doesn't matter where functionality (such as playing mp3s) comes from - the more software you have installed, the more likely it is that some of it has security holes - "opening the window wider" as NeddySeagoon put it.

Personally I would never describe playing music or video as "basic functionality".

 *Aniruddha wrote:*   

> What do you mean with "Check the references in the advisories of the distributors who disclosed the vulnerability"

 

If you look at the bottom of a GLSA you will see a References section containing links to other reports of the same issue, usually the ones from which the GLSA was compiled.  Security advisories for other distros usually have a similar thing.

----------

## PaulBredbury

 *tarpman wrote:*   

> you should be either auditing every line of code that runs on your system personally

 

Even Superman (tm) would be hard-pressed to do that. And he has laser eyesight  :Smile: 

Non-programmers unfortunately do not understand the word "complexity". Millions of lines of code is beyond any human to audit, or even look at with anything but a blank, useless stare.

----------

## Kasumi_Ninja

 *PaulBredbury wrote:*   

>  *tarpman wrote:*   you should be either auditing every line of code that runs on your system personally 
> 
> Even Superman (tm) would be hard-pressed to do that. And he has laser eyesight 
> 
> Non-programmers unfortunately do not understand the word "complexity". Millions of lines of code is beyond any human to audit, or even look at with anything but a blank, useless stare.

 

What would be the best way for a dev to check a package for malware?

----------

## NeddySeagoon

Aniruddha,

Its not the number of repostitories that contributes to security, its installed packages.

If I want a server, I start out with a basic hardened install then add apache and thats all. There is nothing I don't need

No GUI, no FTP, no PHP etc. If I were paranoid, I would build the system in a chroot on another box and not even have a toolchain on the server.

There is no point in giving crackers the means to compile and install stuff.

Gentoo gives you just what you ask for - which is the right place to start.

----------

## PaulBredbury

 *Aniruddha wrote:*   

> check a package

 

Requires going through it with a "fine tooth comb". Could be more effort than programming it in the first place, depending on how much care the original programmers took.

 *Quote:*   

> for malware?

 

Malware should be the easiest to spot, if the source code is available. The usual buffer over/under-runs are more of a concern, which can be exploited. Death to the C language! If everyone programmed in Python, we wouldn't have this problem  :Twisted Evil: 

----------

## Kasumi_Ninja

Ned,

Let me elaborate. Currently I am comparing openSUSE 10.3 and Gentoo. I would like to offer and support one (or both) distributions.Currently I am testing openSUSE 10.3,.Being accustomed to Gentoo I encountered some (in my opinion) weird security practices. openSUSE 10.3 offers few packages on the DVD and relies heavily on thrid-party repositories for additional functionality. These thirdparty repo's are not checked by openSUSE. On top of that they launched the openSUSE Build Service where everyone get get an account and start a repo. Again nothing is checked in these repo's. You can install software from these repositories with 1-Clickl. 

In my opinion are these 3rd party repositories and particularly the openSUSE Build Service with it's '1-Click Install' a security hazard. Since Gentoo provides all functionality in one stable portage tree which is checked by Gentoo 'security team I do think Gentoo offers more security than a approach with few core packages and lot's of third party repositories (Red Hat, openSUSE). Am I right?

----------

## Kasumi_Ninja

 *PaulBredbury wrote:*   

>  *Aniruddha wrote:*   check a package 
> 
> Requires going through it with a "fine tooth comb". Could be more effort than programming it in the first place, depending on how much care the original programmers took.
> 
>  *Quote:*   for malware? 
> ...

 

Hi Paul,

Lol how you divided my question in two   :Laughing: . From your answer I understand that all packages in portage are verified (not checked )for malware like rootkits and is therefor perfectly safe. Off course I realize the chance that malware enters portage is really small. Anyone recall that it ever happened?

Thanks for pointing  towards 'the usual buffer over/under-runs' . This is where hardened Gentoo comes in. Btw Is hardened Gentoo the reason why Gentoo is one of the most secure distributions out there?

----------

## NeddySeagoon

Aniruddha,

Now we have moved away a little from the original question. Anyone can put anything in a binary, including a root kit, and you won't know.

There is no way to check such user contributed binaries except by rebuilding them. Thats effectively what seti@home used does to validate results.

The same data is processed at least twice.

Gentoo builds from source and the portage tree contains checksums of all the files a package needs so you can prove that you are getting what the developer tested when the ebuild was created - ever had a digest failure ?

That was portage detecting something not right.

Its the difficulty of providing security with Gentoo binariers (and the shear number of USE combinations) that have stopped BINHOSTS getting established. If you get a binary (RPM) from Red Hat, its signed - you know it was Red Hat that created it. You trust them with respect to the contents.

If I gave you a binary, you have no way to check that its derived from the sources I say it is. I can gpg sign it, you you know its me but you still have to take the content on trust.

From the binaries perspective, Gentoo is more secure than any distro that allows random users to contribute binaries that get distrubited as Gentoo does not distribute binaries and ebuilds validate the sources against checksums provided by the ebuild dev.

The sources are as provided by ${UPSTREAM} and are not normally security audited by Gentoo.

----------

## Kasumi_Ninja

 *NeddySeagoon wrote:*   

> Aniruddha,
> 
> Gentoo builds from source and the portage tree contains checksums of all the files a package needs so you can prove that you are getting what the developer tested when the ebuild was created - ever had a digest failure ?
> 
> That was portage detecting something not right.

 

And as we concluded in the previous post upstream packages are checked by dev for signs of malware (rootkits, trojans etc) right?

 *Quote:*   

> 
> 
> Its the difficulty of providing security with Gentoo binariers (and the shear number of USE combinations) that have stopped BINHOSTS getting established. If you get a binary (RPM) from Red Hat, its signed - you know it was Red Hat that created it. You trust them with respect to the contents.

 

In short only use a binhost (or any repository for that matter) that you can trust. I was thinking of hosting my own Gentoo bin files on an ftp server. I wonder though is there a change my server gets hacked and the binaries modified without me knowing it ? Or does portage binhost also contain some kind of (md5) checking system?

 *Quote:*   

> 
> 
> From the binaries perspective, Gentoo is more secure than any distro that allows random users to contribute binaries that get distrubited as Gentoo does not distribute binaries and ebuilds validate the sources against checksums provided by the ebuild dev.
> 
> The sources are as provided by ${UPSTREAM} and are not normally security audited by Gentoo.

 

Thanks that is very clear point of view. I do think  rpm packages downloaded form the net are potentially unsafe as *.exe files. Particularly because they are so easy to install.

----------

## Hu

Developers usually take reasonable precautions to ensure that the packages they provide from upstream are the ones that were released by the upstream developer, but I am not aware of any policy which says the developers are required to do so.  Further, the Gentoo developers generally do not do detailed security audits of the packages, so you are still trusting that the upstream author of ${PACKAGE} is not bundling malicious code directly into the officially released package.

Even if the binhost kept an MD5 sum, anyone who gained enough access to replace the package with a malicious equivalent would have enough access to change the stored MD5 sum as well.  If you stored the MD5 sum on some other server, then you face the problem of securely distributing both the package and the checksum.  The most obvious solution is to provide cryptographic signatures of the package, and give all the receiving systems a copy of the appropriate public key.  To the best of my knowledge, Portage does not have sufficiently thorough integration with GPG to handle all of this transparently.  One of the Gentoo developers would know more.

----------

## Kasumi_Ninja

 *Hu wrote:*   

> Developers usually take reasonable precautions to ensure that the packages they provide from upstream are the ones that were released by the upstream developer, but I am not aware of any policy which says the developers are required to do so

 

Anyone knows if there is such a policy? I couldn't find it myself.

 *Quote:*   

> Further, the Gentoo developers generally do not do detailed security audits of the packages, so you are still trusting that the upstream author of ${PACKAGE} is not bundling malicious code directly into the officially released package.

 

Fortunately according to Paul malware is easy to spot   :Smile: . The question remains though; are all Gentoo devs required to check for signs of malware? Is there anyone who knows more about this? 

 *Quote:*   

> Even if the binhost kept an MD5 sum, anyone who gained enough access to replace the package with a malicious equivalent would have enough access to change the stored MD5 sum as well.  If you stored the MD5 sum on some other server, then you face the problem of securely distributing both the package and the checksum.  The most obvious solution is to provide cryptographic signatures of the package, and give all the receiving systems a copy of the appropriate public key.  To the best of my knowledge, Portage does not have sufficiently thorough integration with GPG to handle all of this transparently.  One of the Gentoo developers would know more.

 

Thanks for the information. Maybe is GPG an idea to add in the future  :Rolling Eyes: ? What about the current portage/md5 system? If I am not mistaken this should provide enough security since portage directly downloads from upstream. Am I right?

----------

## NeddySeagoon

Aniruddha,

GPG signing is coming to portage. I'm not sure what this GPG signature will mean over and above the range of checksums applied now.

i.e. what the GPG signature will cover. I believe some of the code is there now too. Read the -dev mailing list for more detail.

Portage downloads from the mirrors in your GENTOO_MIRROR list, only falling back to the SRC_URI if the required file is not found on the mirrors. However, regardless of where you retrieve the package source code from, the same md5sums from the portage tree are applied. Thus an attacker has to craft a package that carries his payload, carries out the original function and has an md5sum collision (and others) with the genuine source, then get you to use it - i.e. get his bogus sources into the gentoo mirror set.

None of the above helps someone wanting to distribute binararies - you are still trusting that the binary you get is what it claims to be but if its signed and there is a problem, you know who the signature belongs to to attribute blame. After your system is compromised, that doesn't help a lot.

----------

## Kasumi_Ninja

Thanks for the answer Ned. If I understand your correctly md5sume verification works perfectly for portage now. And with binary distributions it remains an issue of trust.  

By the way If you want have a laugh look at answer I got about security from the Packman (openSUSE's greatest third-part repo) mailing list:

 *Quote:*   

> Am Samstag, 3. November 2007 schrieb Aniruddha:
> 
> > My basic question is; I do trust
> 
> > you guys, but how good are your security policies? Is the original
> ...

 

----------

## NeddySeagoon

Aniruddha,

For source based builds, portage carries out a number of tests like md5sum on all the files used in the build, including the ebuild file itself.

These checks ensure you start from the same code as the developer tested. They say nothing about the content of the sources.

The content comes back to trust of ${UPSTREAM} and how long you believe deliberately introduced malware would go undetected by 

a) the ${UPSTREAM} project (you need a conspiracy)

b) the community at large (we assume you are not an early user of the package).    

As binaries need an extra step (the build) that can be performed by any group or individual, you are trusting them to not have tampered with the sources, or built it on faulty hardware to get you the package that ${UPSTREAM} intended. There is thus more opportunity to tamper.

At present, there is no way to allow you to derive a "fingerprint" of the resulting binary from the sources without doing the actual build yourself.

In short, for binaries, there is an extra trust step, no matter who does it.

----------

## Kasumi_Ninja

 *NeddySeagoon wrote:*   

> Aniruddha,
> 
> For source based builds, portage carries out a number of tests like md5sum on all the files used in the build, including the ebuild file itself.
> 
> These checks ensure you start from the same code as the developer tested. They say nothing about the content of the sources.

 

Ok I understand that   :Smile: 

 *Quote:*   

> The content comes back to trust of ${UPSTREAM} and how long you believe deliberately introduced malware would go undetected by 
> 
> a) the ${UPSTREAM} project (you need a conspiracy).

 

Lol, ok I got your point.

 *Quote:*   

> 
> 
> b) the community at large (we assume you are not an early user of the package).

 

II almost forgot about the stable/unstable tree. In opinion this is one of the best safeguards.  

 *Quote:*   

> 
> 
> As binaries need an extra step (the build) that can be performed by any group or individual, you are trusting them to not have tampered with the sources, or built it on faulty hardware to get you the package that ${UPSTREAM} intended. There is thus more opportunity to tamper.
> 
> At present, there is no way to allow you to derive a "fingerprint" of the resulting binary from the sources without doing the actual build yourself.
> ...

 

And these problems compound (in openSUSE's case):

-When you rely heavily on third-party repositories

-These third-party repositories don't have  security measures

-There isn't a testing tree, meaning that all new rpm's are immediately available for everyone.

----------

## GNUtoo

 *NeddySeagoon wrote:*   

> Aniruddha,
> 
> The content comes back to trust of ${UPSTREAM} and how long you believe deliberately introduced malware would go undetected by 
> 
> a) the ${UPSTREAM} project (you need a conspiracy)
> ...

 

that is true even if it's a company that freed the code...

for instance they found a back door in a interbase that was liberated and they have seen it and fixed it...(http://www.youtube.com/watch?v=KGlNTEQ0RzM)

(if you want to download the video just ask me)

there is also the fact that they mostly communicate via e-mail or irc...and some users follow theses mailing list...so if they want to make a conspiracy...they must find another way  to comunicate and they must include evry contributor...

and most of the patches are checked before(when you don't have  comit acess) or after inclusion in a project

so the only way to include malware is to "hack" the cvs/svn/whatever or relase system...

this has been done more than once but it has always been rapidely detected:

http://linux.slashdot.org/article.pl?sid=03/11/06/058249

http://linux.slashdot.org/article.pl?sid=03/11/21/1314238

and most important...be carefull on software that aren't free and don't install them...

the problem here is the proprietary dependencies...

you have several solutions:

*use paludis(selinux support???)

*use pkgcore(no selinux support!!!)

*wait for portage 2.2

*help me/wait for me to finish my perl script that mask non-free packages and dependencies

even the ones with the sources...as there are no external contributor...they aren't checked

----------

## Kasumi_Ninja

 *GNUtoo wrote:*   

> that is true even if it's a company that freed the code...
> 
> for instance they found a back door in a interbase that was liberated and they have seen it and fixed it...(http://www.youtube.com/watch?v=KGlNTEQ0RzM)
> 
> (if you want to download the video just ask me)

 

I would like to download the video ^_^

 *Quote:*   

> there is also the fact that they mostly communicate via e-mail or irc...and some users follow theses mailing list...so if they want to make a conspiracy...they must find another way  to comunicate and they must include evry contributor...
> 
> and most of the patches are checked before(when you don't have  comit acess) or after inclusion in a project
> 
> so the only way to include malware is to "hack" the cvs/svn/whatever or relase system...
> ...

 

Thanks for the links!

 *Quote:*   

> and most important...be carefull on software that aren't free and don't install them...
> 
> the problem here is the proprietary dependencies...
> 
> you have several solutions:
> ...

 

I am sorry I can't code (yet)

 *Quote:*   

> 
> 
> even the ones with the sources...as there are no external contributor...they aren't checked

 

What fo you mean exactly? And what do you think of my analysis of openSUSE's security?

 *Aniruddha wrote:*   

> 
> 
> And these problems compound (in openSUSE's case):
> 
> -When you rely heavily on third-party repositories 
> ...

 

----------

## arach

Portage has two huge security holes that paludis doesn't: priv escalation via portage cache files and insecure uninstallation of set*id files which leaves systems vulnerable to rooting even after insecure packages have been upgraded.

----------

## GNUtoo

 *Aniruddha wrote:*   

> 
> 
> I would like to download the video ^_^
> 
> 

 

use one of the following website:

http://keepvid.com/

http://www.mediapirate.org/

or there is that:

```
net-misc/youtube-dl [ Masked ]

      Latest version available: 2007.10.12

      Latest version installed: [ Not Installed ]

      Size of files: 14 kB

      Homepage:      http://www.arrakis.es/~rggi3/youtube-dl/

      Description:   A small command-line program to download videos from YouTube.

      License:       MIT
```

 *Quote:*   

> 
> 
> What fo you mean exactly?
> 
> 

 

i mean that things that have the source like microsoft shared source initiative is even a security risk becase:

->it may not be documented

->nobody get interested in something you can't modify

in linux you have sevral project that have the sources but they are not free and may not be checked...

such as:

->opera

->mabe blackdown(i don't remember well the license)

 *Aniruddha wrote:*   

> 
> 
> And these problems compound (in openSUSE's case):
> 
> -When you rely heavily on third-party repositories 
> ...

 

=>this is very problematic

are theses binairies or binairies+sources like in debian/ubuntu?

do you know checkinstall?

----------

## NeddySeagoon

GNUtoo,

 *Quote:*   

> *help me/wait for me to finish my perl script that mask non-free packages and dependencies 

 

I think portage understands LICENCE="..." in make.conf, just like USE, so you may not need your script.

----------

## Kasumi_Ninja

 *GNUtoo wrote:*   

> are theses binairies or binairies+sources like in debian/ubuntu?
> 
> do you know checkinstall?

 

Sometimes source rpm's are provided although it is not mandatory. You can find more info here:

http://software.opensuse.org/search

http://download.opensuse.org/repositories/

http://packman.links2linux.org/packages

I found the security risk so severe (particularly the openSUSE build service) that I stopped recommending openSUSE to beginners. I know checkinstall but that is a potentially disastrous tool since it overwrites anything without checking.

----------

## spb

 *NeddySeagoon wrote:*   

> I think portage understands LICENCE="..." in make.conf, just like USE, so you may not need your script.

 

https://bugs.gentoo.org/show_bug.cgi?id=17367

Still open, so I'd guess not... I do know paludis has supported such license filtering pretty much from the beginning though.

----------

