when adding bad code 'echo pwd>/etc/passwd' to an ebuild it can be executed with root permission when the package is emerged. when a faulty SRC_URI is given, there is no warning about an access violation. this works even when the ebuild is owned by a user. i think this is sort of a security flaw, especially for people who have PORTDIR_OVERLAY enabled. if a user can alter an ebuild there... there should be some sort of check for what is allowed in an ebuild and what not. and portage should not use ebuilds which are world writeable or belong to someone else than root. i'll attach two ebuilds which demonstrate this - 'acces-violation' gives a warning but executes the bad code nonetheless, whereas 'no-warning' just fails to download, but executes the code too. the ebuilds will 'echo foo>/etc/badcode'. i masked them by keywords to prevent accidential execution. i dont know if this hasnt been covered before somewhere - if so i'm sorry, but i wasnt able to find it. this issue was raised by a user in the forum who claimed that he was able to achieve similar results not by emerging but by searching 'emerge -s' - i was not able to reproduce this. link: http://forums.gentoo.org/viewtopic.php?p=624139 Reproducible: Always Steps to Reproduce: 1. save ebuild in PORTDIR_OVERLAY 2. chown someuser 3. emerge as root
Created attachment 20156 [details] ebuild dies with acces violation, but executes possible malicious code first one...
Created attachment 20157 [details] ebuild executes malicious code without warning second one...
If a malicious user attaches malicious code in anyway to an ebuild in any section your pretty much fubared.
I'm the user of the forum the reporter talked about. when you put echo foo>/bar between those environment variable assignments of a random ebuild, this gets also executed when you do an emerge -S (emerge --searchdesc). Verified that. My mistake for saying -s (normal search). Of course when the box is compromised, the lamer has root access anyway, so why edit things like that then? BUT... those ebuilds get downloaded from a rsync box. What if one of those boxes get compromised and distribute bad ebuilds to gentoo boxes? Is that assured not to happen? That would be very bad. please reconsider reopening this bug in that case... :/
> between those environment variable assignments of a random ebuild, this gets > also executed when you do an emerge -S (emerge --searchdesc). Verified that. > My mistake for saying -s (normal search). any operation that sources the ebuild will execute commands if the command is not in a function (like src_compile, etc...) you can't really block that because sometimes you need to execute commands in global scope ... > Of course when the box is compromised, the lamer has root access anyway, > so why edit things like that then? BUT... those ebuilds get downloaded from > a rsync box. What if one of those boxes get compromised and distribute bad > ebuilds to gentoo boxes? Is that assured not to happen? That would be very > bad. there is already talk of doing ebuild signing (search bugzilla/mailing lists for it) so this shouldnt be a problem ... but at this point, if an rsync box gets owned, then it doesnt matter where you put the code, your box is dead as soon as the package is given to `emerge` :P > please reconsider reopening this bug in that case... :/ no, see ebuild signing
Well you both are right this is exactly what would happen if a rsync server were to become compromised. However this bug was marked INVALID because no solution exists to prevent such a things. Gentoo Linux can not guarantee the security of any of it's mirrors, and anything crafty we could code into portage such as ebuild signatures and the such could always be subverted in some shape form or manor. So in the end.. If a mirror becomes compromised and a malicious user injects some code in any area such as files/* or even entire trojaned ebuilds with altered md5sums the end user is screwed and should end up kissing her/his network away... secure ebuild transport has been a hot topic for a while now, but not a single person has come up with a solution that can withstand 15 mins of public scrutiny. However if you come up with any solutions that can withstand public scrutiny we are all ears.
oh boy - i knew this would happen ;) i know that there is a lot of talk about keys, masterkeys, md5 checks and rechecks of sources. and i know that a ebuild has to be able to execute shell code. what i did not know so far, was that it is very easy to exploit this *locally* - how about a quick check if PORTDIR_OVERLAY is writable by everyone, if the ebuild belongs to root and is only root writeable. cant hurt imho - this is certainly not the answer to the ebuild distribution problem but it cant hurt to add a level to the local security by using these easy checks. some other things come to my mind - existing files in CONFIG_PROTECT should not be able to get altered by bad ebuild code. right now i can 'echo foo>>/etc/passwd' out of an ebuild - are there cases where this is necessary? thats just my opinion - if the policy is: 'when root cannot keep the permission on his system tidy its his own fault', well then its ok for me too. in this case a security note regarding portdir_overlay in make.conf wouldnt hurt imho.
pretty much all of your ideas are taken care of userpriv FEATURE
perhaps i'm doing something wrong then - i have it enabled and i'm still able to append to files in /etc
are you running as root still ? ;)
Any admin who do not setup privs correctly, or give sudo/su/portage privs to users he do not trust, cannot expect any better. How far is too far in protecting somebody who are anyhow prob going to dd if=<whatnot> of=/dev/hda anytime soon ? (OK, so maybe a bit far fetched, but if you do not know the basics of security, sell your box, lock it up in a safe without a network cable anywhere in site, etc =).
