Comment by LukeShu
8 years ago
> yes, this is a fundamental problem with the security model of Arch Linux
No, it's not. AUR is not Arch, and is not "supported" by Arch.
It's a fundamental problem with the security model running code from randos on the internet. If someone published a git repo on GitHub that installed malware when you ran
git clone git://github.com/user/repo . && ./configure && make && sudo make install
you wouldn't be saying that "this is a fundamental problem with the security model of git."
From the AUR homepage, in big text:
> AUR packages are user produced content. Any use of the provided files is at your own risk.
AUR has the word "Arch" in its name and is linked right at the top of the Arch Linux homepage and from every Arch Linux webpage. So it's disingenuous to claim it is "not Arch.”
Contrast this to the old debian-multimedia, which had no links from Debian.org and which eventually yielded to pressure to change its name to make clear that it was not part of Debian.
Just to emphasize how little AUR is supported by Arch:
Even the 'AUR helpers' aren't part of the normal Arch repositories. So if you wan't a less manual access to the AUR you have to install such a program manually.
And the Arch Wiki states:
[1]: https://wiki.archlinux.org/index.php/AUR_helpers
I understand your point but the problem is that the title is "Arch Linux AUR Repository Found to Contain Malware" (and not, for example: "AUR Repository Found to Contain Malware"). I would argue that the implication (I guess reputation-wise if that matters) starts with the "Arch Linux" part. It's easy to jump on Arch because of this regardless of the fact that the AUR is not supported. At a cursory glance plenty of people (though incorrect) will equate this to "Arch Linux contains malware"
This isn't unique to Linux.
Most people would read "Apple App Store Found to Contain Malware" as "Apple Devices Found to Contain Malware" too.
The App Store is closer to the official Arch repos, since it is vetted by Apple. The AUR is closer to just downloading stuff off the Internet.
AUR PKGBUILDs are much more restricted than this, since they're restricted to a fakeroot.
Of course, if you're ultimately going to run the program, the binary set up by the PKGBUILD has a lot of control. But the PKGBUILD itself is limited in what it can do (to things like listing your installed packages, getting `uname -a`--the stuff mentioned in the article).
No. Whatever you stick in the install= file will run as root at install time. If you're using an AUR helper/running `makepkg -i`, the PKGBUILD absolutely can run code as root, without waiting for you to interact with the installed program. Installing a package from a PKGBUILD is no more or no less "powerful" to an attacker than `make && sudo make install`.
The install hooks are chrooted inside the pacman install directory.
But, yeah, they run as root, so they can still do damage.
My point was that the danger zone is when you trust the package, rather than when you run the PKGBUILD itself with `makepkg`. Of course `makepkg -i` runs both `makepkg` and `pacman` as root.