How to inspect AUR package PKBUILD and .install files

supernerd · 2014-06-25 10:15:48

Hi,

Linux and arch newbie here. I was reading the wiki article about the AUR and noticed this bit:

Warning: Carefully check all files. cd to the newly created directory and carefully check the PKGBUILD and any .install file for malicious commands. PKGBUILDs are bash scripts containing functions to be executed by makepkg: these functions can contain any valid commands or Bash syntax, so it is totally possible for a PKGBUILD to contain dangerous commands through malice or ignorance on the part of the author. Since makepkg uses fakeroot (and should never be run as root), there is some level of protection but you should never count on it. If in doubt, do not build the package and seek advice on the forums or mailing list.

This is something that have not been doing at all in the past, but I am trying to improve my practices managing my system.

The problem is, I do not know what exactly I am looking at or for in these files. If I give these files a look over before installing the package, can I honestly expect to spot something malicious? What would I need to learn to notice if something was fishy?

Anyway, I am not to worried about this practically, because I only use a handful of AUR packages and I usually install ones based on recommendations, not just at random. But it still seemed interesting for the wiki to stress this so strongly. How important is this guidline anyway?

Thanks!

[EDIT: spelling]

Last edited by supernerd (2014-06-25 10:41:13)

karol · 2014-06-25 10:49:39

You need to read the whole PKGBUILD and understand what it is doing and why.

supernerd · 2014-06-25 10:59:33

karol wrote:

You need to read the whole PKGBUILD and understand what it is doing and why.

Understanding 'what' is not so difficult usually. It is understanding 'why' that seems hard I guess.

jasonwryan · 2014-06-25 17:12:59

In case there is something broken (consciously or unconsciously) in there...

tomk · 2014-06-25 19:23:01

supernerd wrote:

The problem is, I do not know what exactly I am looking at or for in these files. If I give these files a look over before installing the package, can I honestly expect to spot something malicious? What would I need to learn to notice if something was fishy?

bash, mainly.

More seriously, we have no idea what you know already, despite your self-confessed but totally undefined newbie status. If you really want to learn, read lots of PKGBUILDs, preferably official ones rather than AUR ones, read relevant documentation, relate what you see in the PKGBUILDs to what happens on your system when you actually install the packages.

supernerd wrote:

How important is this guidline anyway?

Ehmm... did you read the DISCLAIMER on the AUR's front page?

GSF1200S · 2014-06-29 10:12:11

I scan the whole PKGBUILD. I start by ensuring that the source link to the original source looks accurate. For example, take the source line for gmusicbrowser-git:

source=("${pkgname}::git+http://github.com/squentin/gmusicbrowser.git")

I know this is the correct link to the source, and so it passes my check. But suppose it had said:

source=("${pkgname}::git+http://youvebeenhackedhub.com/1337haxorz/gmusicbrowser.git")

I would become suspicious. Of course this is an exaggeration, but common sense goes a long ways here. At least check the first time..

With the source verified, I ensure that the md5sum or sha256sum block has a sum. This way, if a download is compromised at the source, the sha256 or md5sum can catch it before you installed (this assumes that the PKGBUILD is not "bad" and has the sum number of a package that wasnt compromised). Note that with git this isnt necessary (the git process protects against such problems). Anytime a tarball is downloaded and extracted however, the sums should be present in the PKGBUILD. If I go to install an AUR package that has 'SKIP' for the md5sum/sha256sum block, I will double or triple check the source of the tarball (or of the patch files enclosed in the build directory, etc..)

I also look for any "dangerous" commands in the build and install sections. For example, if I see "rm -rf" I had better see something like $pkgdir to start the directory path or be VERY sure the path is "safe". Since makepkg is not run as root this should theoretically not be a problem, but imagine if someone put "rm -rf /home/*" (warning: do not run that command on your system!) in there! This is mostly common sense; in time as you get more comfortable with bash and various linux commands it will make more and more sense and you will be able to spot mistakes.

Also, consider the user posting the pkgbuild. "Trusted Users" are selected as trustworthy members of the community, so obviously you can feel much more comfortable with PKGBUILDS they have made (Xyne comes to mind..). For people you may not know, check what other PKGBUILDs they have available. After awhile, you develop a trust for certain people whos PKGBUILDs or software you have used. For example, I wouldnt hesitate to build/install using a PKGBUILD put up by BurntSushi since I use some of his software, have personally corresponded with him, and find him to be responsible. You might "develop" such rapport with other AUR users I dont even know about.

Consider the vote count of a package as an approximate metric. Dont discount a package because it has 0 votes- it may just be that not many people have use for that particular software. Ive considered hosting a PKGBUILD for "xfce4-terminal-nowindowhints"; consider that tilers generally ignore them anyway, and that my package would only be useful for someone literally using xfce4-terminal with pytyle. How high do you think the vote count would be (even if the PKGBUILD had 0 errors)? On the other hand, you at least have a good chance the PKGBUILD is solid if the package has 354 people voting for it.. That said, the package could have been well-maintained before (when it received a ton of votes), and the quality has dropped since- just be mindful of these trends.

Finally, adding all of these things together will leave the odds of a malicious PKGBUILD affecting your system pretty slim, though its certainly not impossible. I have never (to my knowledge to be fair) encountered a malicious PKGBUILD, though I have found a few that had errors or outdated sources, etc.

Last edited by GSF1200S (2014-06-29 10:13:50)

stevenhoneyman · 2014-06-29 12:43:36

Some can be more covertly modified than others though... like this

GSF1200S is right though, if you check the source is good, that's the first/easiest thing to notice.

cfr · 2014-06-30 01:42:05

GSF1200S wrote:

I also look for any "dangerous" commands in the build and install sections. For example, if I see "rm -rf" I had better see something like $pkgdir to start the directory path or be VERY sure the path is "safe". Since makepkg is not run as root this should theoretically not be a problem, but imagine if someone put "rm -rf /home/*" (warning: do not run that command on your system!) in there! This is mostly common sense; in time as you get more comfortable with bash and various linux commands it will make more and more sense and you will be able to spot mistakes.

Another possible safeguard is not to run makepkg as a user who could do much damage by running such a command. You can use a user who can only delete AUR stuff and similar. That is, don't run makepkg as your normal user --- make it so that makepkg cannot delete your almost-complete doctoral thesis or those graphics you've almost finalised for the client that needs them tomorrow. Don't let makepkg touch your own stuff just in case a build is malicious or somebody screws up and you miss it.

I know there is stuff I wouldn't catch. I do not understand everything in every PKGBUILD I use. (Maybe I should but I don't.) But I can look for the obvious things and I can mitigate the potential damage makepkg can do.

Note that since you install as root, using another user to run makepkg won't protect against malicious or buggy install files. However, these are mostly simpler and easier to parse.

Despite knowing there's stuff I won't catch, I have caught stuff I don't like. Sometimes I've commented out the code and used the file (and posted a comment). But in those cases what I've not liked has been non-KISS rather than nasty. If I found something nasty, obviously I wouldn't proceed at all.

Last edited by cfr (2014-06-30 01:43:44)

GSF1200S · 2014-06-30 02:54:15

cfr wrote:

GSF1200S wrote:
I also look for any "dangerous" commands in the build and install sections. For example, if I see "rm -rf" I had better see something like $pkgdir to start the directory path or be VERY sure the path is "safe". Since makepkg is not run as root this should theoretically not be a problem, but imagine if someone put "rm -rf /home/*" (warning: do not run that command on your system!) in there! This is mostly common sense; in time as you get more comfortable with bash and various linux commands it will make more and more sense and you will be able to spot mistakes.
Another possible safeguard is not to run makepkg as a user who could do much damage by running such a command. You can use a user who can only delete AUR stuff and similar. That is, don't run makepkg as your normal user --- make it so that makepkg cannot delete your almost-complete doctoral thesis or those graphics you've almost finalised for the client that needs them tomorrow. Don't let makepkg touch your own stuff just in case a build is malicious or somebody screws up and you miss it.
I know there is stuff I wouldn't catch. I do not understand everything in every PKGBUILD I use. (Maybe I should but I don't.) But I can look for the obvious things and I can mitigate the potential damage makepkg can do.
Note that since you install as root, using another user to run makepkg won't protect against malicious or buggy install files. However, these are mostly simpler and easier to parse.
Despite knowing there's stuff I won't catch, I have caught stuff I don't like. Sometimes I've commented out the code and used the file (and posted a comment). But in those cases what I've not liked has been non-KISS rather than nasty. If I found something nasty, obviously I wouldn't proceed at all.

Thats a very good idea- I will have to do just that.

I agree there are things you just wont catch, so it is important to mitigate any possibility through such an approach.

Arch Linux

#1 2014-06-25 10:15:48

How to inspect AUR package PKBUILD and .install files

#2 2014-06-25 10:49:39

Re: How to inspect AUR package PKBUILD and .install files

#3 2014-06-25 10:59:33

Re: How to inspect AUR package PKBUILD and .install files

#4 2014-06-25 17:12:59

Re: How to inspect AUR package PKBUILD and .install files

#5 2014-06-25 19:23:01

Re: How to inspect AUR package PKBUILD and .install files

#6 2014-06-29 10:12:11

Re: How to inspect AUR package PKBUILD and .install files

#7 2014-06-29 12:43:36

Re: How to inspect AUR package PKBUILD and .install files

#8 2014-06-30 01:42:05

Re: How to inspect AUR package PKBUILD and .install files

#9 2014-06-30 02:54:15

Re: How to inspect AUR package PKBUILD and .install files

Board footer