<SOLVED>Security considerations on AUR

Fred Barclay · 2016-12-04 22:05:50

Hullo mates! Long-time LMDE user here looking to jump into Arch. I've dabbled a bit with it in the past and I think it may be time to put Arch through its paces and possibly consider a switch.

So, having read the wiki article about the AUR and duly noting the warnings, I've got just one question/clarification:
How can I verify that a package on the AUR is not malicious, whether intentionally or by accident, if I've already verified that the source code is fine?

As an example, firejail is already available in Community, but let's say I wanted to install firejail-git from the AUR. I have already read all the source code on GitHub to firejail and I trust it. Looking at the snaphot I downloaded from the AUR, I see two files: .SRCINFO and PKGBUILD. I've read both of them and they look fine as well. At this point, can I be reasonably certain that running makepkg and then installing the .pkg.tar.xz file is safe?

What would be common pitfalls to look out for? It seems like it would be a good idea for me to check the source url in PKGBUILD (in this case git+https://github.com/netblue30/firejail.git) and make sure it resolves to a trusted url; is that correct?

Any other suggestions/ideas/warnings?

Thanks!

Last edited by Fred Barclay (2017-01-02 02:39:37)

R00KIE · 2016-12-04 22:13:31

I'd say "all" you have to do is read the PKGBUILD and make sure it is downloading the right sources and it isn't doing anything fishy. Another thing to pay attention to is any .install files, as those will run when the package is installed.

ewaller · 2016-12-04 22:17:41

Fred Barclay wrote:

So, having read the wiki article about the AUR and duly noting the warnings, I've got just one question/clarification:
How can I verify that a package on the AUR is not malicious, whether intentionally or by accident, if I've already verified that the source code is fine?

Aye, there's the rub. All of the auditing of PKGBUILDS, the verification of hashes, the signatures of the maintainers are all great. You can verify that the code you are going to run is the code that the person who packed it intended you to run. The question is, what is it they intend for that source code to do? Aside from auditing the code, or following community sensus that a given set of source files are safe and verifiable, all you can do is decide the extend to which you trust the entity that wrote that code.

Edit: Having re-read your post I could take a different take on it. You do understand that AUR "Packages" are not binaries, but rather build the package from source (generally). So, if you have read and trust the source, the package itself will be built by you on your machine -- it does not come from the AUR.

Last edited by ewaller (2016-12-04 22:20:20)

Fred Barclay · 2016-12-06 18:27:08

ewaller wrote:

ou do understand that AUR "Packages" are not binaries, but rather build the package from source (generally).

Correct - that is what I was thinking.

So if I can trust the source, and if the PKGBUILD and any other included files look good, then I can trust the resulting package when I build it, right?

ewaller · 2016-12-06 18:37:03

Fred Barclay wrote:

So if I can trust the source, and if the PKGBUILD and any other included files look good, then I can trust the resulting package when I build it, right?

I do, certainly where it comes to my security. Were I protecting other peoples' sensitive data I might check more closely.

brebs · 2016-12-06 19:55:40

Would you spot a sneaky, malicious code change in C code?

ewaller · 2016-12-06 20:08:53

Nope

The presumption was that the source is trusted and that it not become adulterated.

brebs · 2016-12-06 22:57:58

Fred Barclay wrote:

How can I verify that a package on the AUR is not malicious, whether intentionally or by accident...

"Malicious" means it was intentional, so what are you asking?

There aren't "common pitfalls", because AUR packages aren't hand grenades. BASH isn't the safest of languages, but pkgbuild scripts are small enough for weirdness to be obvious to at least some of the observers.

Fred Barclay · 2016-12-08 16:33:54

brebs wrote:

"Malicious" means it was intentional, so what are you asking?

Hmmm... what would be the proper word then? I mean that the code is harmful or presented a security threat, even if it were not the author's intent.

ewaller wrote:

Were I protecting other peoples' sensitive data I might check more closely.

Could you explain a bit more? What might you check more closely?

ewaller · 2016-12-08 16:57:45

Is there a point to this thread on which we can converge? Or is this a never ending philosophical discussion?

Specifically, say you were building a system that processed credit card transactions -- you would probably want to take the steps necessary to meet the requirements of PCI-DSS. This would include code reviews, penetration testing and surveillance of the system watching for attacks. A system that processes classified information for the US department of energy might want to look at a document like DOE M 471.2-2 for guidance. There are endless examples of requirements documents that you can use in your Systems Engineering process.

Last edited by ewaller (2016-12-08 18:35:51)

Alad · 2016-12-08 17:00:20

Fred Barclay wrote:

Could you explain a bit more? What might you check more closely?

For example, can you trust your compiler? cf. https://reproducible-builds.org/docs/

However, this is a general topic and outside the scope of the AUR.

Last edited by Alad (2016-12-08 17:01:10)

ewaller · 2016-12-08 18:02:36

Alad wrote:

For example, can you trust your compiler?

$DEITY, I love reading Ken Thompson. Nice Link

Fred Barclay · 2017-01-02 02:39:10

ewaller wrote:

Is there a point to this thread on which we can converge? Or is this a never ending philosophical discussion?

Sorry for the late reply - been busy encrypting my disk and installing Arch + the holidays. I must have misunderstood your earlier post - I had thought you meant that if you were helping a friend with the AUR that you might be more careful than if you yourself were installing something from it. Anyways, I see what you mean now.

Thanks to everyone who helped me! I feel a bit better about the AUR now.

Last edited by Fred Barclay (2017-01-02 02:41:10)

Arch Linux

#1 2016-12-04 22:05:50

<SOLVED>Security considerations on AUR

#2 2016-12-04 22:13:31

Re: <SOLVED>Security considerations on AUR

#3 2016-12-04 22:17:41

Re: <SOLVED>Security considerations on AUR

#4 2016-12-06 18:27:08

Re: <SOLVED>Security considerations on AUR

#5 2016-12-06 18:37:03

Re: <SOLVED>Security considerations on AUR

#6 2016-12-06 19:55:40

Re: <SOLVED>Security considerations on AUR

#7 2016-12-06 20:08:53

Re: <SOLVED>Security considerations on AUR

#8 2016-12-06 22:57:58

Re: <SOLVED>Security considerations on AUR

#9 2016-12-08 16:33:54

Re: <SOLVED>Security considerations on AUR

#10 2016-12-08 16:57:45

Re: <SOLVED>Security considerations on AUR

#11 2016-12-08 17:00:20

Re: <SOLVED>Security considerations on AUR

#12 2016-12-08 18:02:36

Re: <SOLVED>Security considerations on AUR

#13 2017-01-02 02:39:10

Re: <SOLVED>Security considerations on AUR

Board footer