[arch-general] Why is it dangerous to run makepkg as root?
Hi, I'm using arch for about half a year on a few systems, but every time I install something from aur I'm asking myself one question: Why is it considered dangerous to run makepkg as root? My first guess was that the PKGBUILD usually comes from an untrusted source and may contain code to attack my system (copy personal data or install a rootkit or something like that). But on the other hand, this file tells makepkg how to build the package that will be installed as root, so if the author of the PKGBUILD has bad purposes he will just put that code into the created package. The second idea is that this advice should prevent the script from *accidentally* damage my system. But this could be prevented by using fakeroot (which is disabled when calling makepkg with --asroot according to the manpage) or chroot. And actually the proper advice in this case should be to execute makepkg using a user dedicated for this, as for most arch users it would be worse if their personal file get deleted as if the system becomes unbootable. Regards, Roland
The second idea is that this advice should prevent the script from *accidentally* damage my system. But this could be prevented by using fakeroot (which is disabled when calling makepkg with --asroot according to the
manpage) or chroot. And actually the proper advice in this case should be to execute makepkg using a user dedicated for this, as for most arch users it would be worse if their personal file get deleted as if the system becomes unbootable. I agree. A good idea is to automatically change to a much more restricted user, used just for building (no shells, logins, etc.). Chroot is too much of a hassle with, most of times, no point. You'll have to deal with dependent libs etc. etc. etc. A good option here could be to hardlink/copy the files of the dependencies inside the chroot temporary in order to do the job. But still, I think it's too much. You should check the scripts on your own...
Hi,
A good idea is to automatically change to a much more restricted user, used just for building (no shells, logins, etc.).
What do you think about patching yaourt to that it, if executed as root, runs makepkg as a special user? Or changing makepkg to drop it's own privileges if executed as root? Regards, Roland
On May 17, 2014 5:22:32 PM EEST, Roland Tapken <ml@lalamuhkuh.de> wrote:
Hi,
A good idea is to automatically change to a much more restricted user, used just for building (no shells, logins, etc.).
What do you think about patching yaourt to that it, if executed as root, runs makepkg as a special user? Or changing makepkg to drop it's own privileges if executed as root?
Regards,
Roland
Both. Yaourt to ensure that you did not download anything via root (and have permission/security problems etc.) Makepkg patch for those who do not use yaourt. Makepkg HAS to create a special user on install, or use the nobody user. I would really like to help patching, but my time is extremely limited (finals in 2 weeks). Good luck! :) BTW: Another good idea that would be helpful is add comments on installed packages on pacman. e.g. why did you install them. But that's another thread
Hi,
I would really like to help patching, but my time is extremely limited (finals in 2 weeks).
Good luck! :)
I'll think I'll have a try, also my time is very limited, too :-) Regards, Roland
On 05/17, Dimitris Zervas wrote:
On May 17, 2014 5:22:32 PM EEST, Roland Tapken <ml@lalamuhkuh.de> wrote:
BTW: Another good idea that would be helpful is add comments on installed packages on pacman. e.g. why did you install them. But that's another thread
No offense, but if you need to ask yourself why you installed something *after* you installed it you almost certainly never needed it in the first place, and if you need the package manager to *tell you* why you installed it you're being careless. If you're installing something just to try it out then do so, and if you don't care for it then uninstall it right away. If you're wondering what use you might have thought you had for that package some time after installing it, the package description should give you some clue. What you're suggesting is that someone write extra code for a feature that encourages carelessness and laziness. It stands to reason that if an explicitly installed package is sitting on your system and it isn't a dependency, and you can't recall putting it to use, it can be removed. -- "A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools." - Douglas Adams
On Sun, May 18, 2014 at 12:57 AM, Bigby James <bigby.james@crepcran.com> wrote:
On 05/17, Dimitris Zervas wrote:
On May 17, 2014 5:22:32 PM EEST, Roland Tapken <ml@lalamuhkuh.de> wrote:
BTW: Another good idea that would be helpful is add comments on installed packages on pacman. e.g. why did you install them. But that's another thread
No offense, but if you need to ask yourself why you installed something *after* you installed it you almost certainly never needed it in the first place, and if you need the package manager to *tell you* why you installed it you're being careless. If you're installing something just to try it out then do so, and if you don't care for it then uninstall it right away. If you're wondering what use you might have thought you had for that package some time after installing it, the package description should give you some clue. What you're suggesting is that someone write extra code for a feature that encourages carelessness and laziness. It stands to reason that if an explicitly installed package is sitting on your system and it isn't a dependency, and you can't recall putting it to use, it can be removed.
makedeps of AUR packages, for one. Or optdeps.
On 05/18, Oon-Ee Ng wrote:
On Sun, May 18, 2014 at 12:57 AM, Bigby James <bigby.james@crepcran.com> wrote:
On 05/17, Dimitris Zervas wrote:
On May 17, 2014 5:22:32 PM EEST, Roland Tapken <ml@lalamuhkuh.de> wrote:
BTW: Another good idea that would be helpful is add comments on installed packages on pacman. e.g. why did you install them. But that's another thread
No offense, but if you need to ask yourself why you installed something *after* you installed it you almost certainly never needed it in the first place, and if you need the package manager to *tell you* why you installed it you're being careless. If you're installing something just to try it out then do so, and if you don't care for it then uninstall it right away. If you're wondering what use you might have thought you had for that package some time after installing it, the package description should give you some clue. What you're suggesting is that someone write extra code for a feature that encourages carelessness and laziness. It stands to reason that if an explicitly installed package is sitting on your system and it isn't a dependency, and you can't recall putting it to use, it can be removed.
makedeps of AUR packages, for one. Or optdeps.
If one builds packages using makepkg (and not something entirely automated) then one would install dependencies sequentially using --asdeps. makedeps that aren't needed by the installed package after compilation can be removed immediately after the desired AUR package is installed using 'sudo pacman -Rncs $(pacman -Qdtq).' I've had that set to an alias for years now. ;) When removing a package it's a good idea to use 'pacman -Rncs' or 'pacman -Rncu' (depending on the situation) to completely remove every trace of it, avoiding leaving orphaned packages and files on the system. Pacman is able to remove optional dependiencies along with the package that optionally uses it, provided the optdepend isn't needed for another explicitly installed package. And the description of any package should clue you in as to what purpose it serves on your system; if it doesn't, then perhaps a change of habit is called for. Basically, the functionality to determine what's on your system and why is already built into pacman; it just requires reading the manpage and figuring out which flags to chain together. Adding a new feature to allow people to make notes on *why* they installed something provides one with an incentive to simply install things on the system without regard, figuring they can just be cleaned up later, and that feature's effectiveness depends entirely on the user writing meaningful notes---and if one is able to think up and write meaningful notes at install time, one is probably already situationally aware and self-aware enough to know and remember why a package was installed. It's like collecting things with the intention of taking them home and sticking them in the closet, only to ask yourself a year later what all the crap in the closet is doing there. You can write and attach notes to all those things, but that amounts to more time spent reading notes later, and plays into the habit of impulsively collecting worthless crap. -- "A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools." - Douglas Adams
May I remind everyone that makepkg is a bash script. Some might argue it's bloated and too long, while others might counter that the discussion is going on way too long already and forking a bash script for personal use would generally be an option. I'd be glad if the devs kept things "generally" working. Thank you. cheers! mar77i
On Sat, May 17, 2014 at 03:49:49PM +0300, Dimitris Zervas wrote:
The second idea is that this advice should prevent the script from *accidentally* damage my system. But this could be prevented by using fakeroot (which is disabled when calling makepkg with --asroot according to the
manpage) or chroot. And actually the proper advice in this case should be to execute makepkg using a user dedicated for this, as for most arch users it would be worse if their personal file get deleted as if the system becomes unbootable. I agree. A good idea is to automatically change to a much more restricted user, used just for building (no shells, logins, etc.). Chroot is too much of a hassle with, most of times, no point. You'll have to deal with dependent libs etc. etc. etc. A good option here could be to hardlink/copy the files of the dependencies inside the chroot temporary in order to do the job. But still, I think it's too much. You should check the scripts on your own...
There is already a package maintained by the Arch devs called 'devtools'¹ specifically for building packages in a chroot, among other things. ¹: https://www.archlinux.org/packages/extra/any/devtools/ Thanks, -- William Giokas | KaiSforza | http://kaictl.net/ GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 17.05.2014 14:40, schrieb Roland Tapken:
Hi,
I'm using arch for about half a year on a few systems, but every time I install something from aur I'm asking myself one question:
Why is it considered dangerous to run makepkg as root?
My first guess was that the PKGBUILD usually comes from an untrusted source and may contain code to attack my system (copy personal data or install a rootkit or something like that). But on the other hand, this file tells makepkg how to build the package that will be installed as root, so if the author of the PKGBUILD has bad purposes he will just put that code into the created package.
The second idea is that this advice should prevent the script from *accidentally* damage my system. But this could be prevented by using fakeroot (which is disabled when calling makepkg with --asroot according to the manpage) or chroot. And actually the proper advice in this case should be to execute makepkg using a user dedicated for this, as for most arch users it would be worse if their personal file get deleted as if the system becomes unbootable.
Regards,
Roland
Hey Roland, there is a general security principle called "Principle of least privilege", which roughly says, that one should give a user/process/... only the minimum of privileges it neads to accomplish its tasks. makepkg does not need root privileges to build packages, so do not give those to it. makepkg does a lot of crazy things - downloading stuff, excuting scripts and complex programs (compilers, ...) - a single bug in one of those can render your system unusable, when executed as root. I think your idea of a dedicated user is great and would implement the principle mentioned above even better. [0] https://en.wikipedia.org/wiki/Principle_of_least_privilege Cheers, ushi -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJTd13uAAoJEAAoDO4PlX3gjLMP/iR+JhKPygx49kFTNktgEbt7 r97BJcHUgPnglRl+w7LjHOJYSYRuNt7FclDK5l4iK0Kog0yrBqohL2wVsIa/ehTF jm/npxpjD0RWtr8nKSTyujlB/deVCV+TiHao+NiRbDFhkORhx8R7ohAw3pgwG8j6 vXkWpZ3NbOxx7G76xXd9YF9dqCFEddIFZ2gFgXaOgaRuMWAe5SdpW1fvpyRcv37v QJdbnzlQoafkTCZKF98inuf2lJKTYBHfaOZJsh3Q5KUS1a6a/qBIvqNQdWNPu1la FtBwwEQ3ku5XeldLi2D0wH4ZRsSBsqCxjXqav/PDyxUDBiTmfBllAToq6o4mGsCM zPCc/P7JvLMNIwMSxf6rXg8lEEIUP867Srx91hY5hdQeINfS1BoX67vq+5FuI5+Q voBfwxl+nSVPdeYydg12xsF91LNW1gUgSd6nVDHcOZX1gPxjZvA3Qin6EYf50pP7 8qVuxzp8qboxmsECKRZgMaAzenGBK482hGjPIkhgQ/n+uU46tGOHlmY1E4QstCoo rzovvzelN0bRdphsClYGmoT4gm/Axbnbhti4WkXYjVjfz8RK6yujV5b3VIdkoPM5 QWJdrbW5wb2Mm2Rvi9UUSqXy6LvK89d0ue2Nu/P4WubbUhq4ZcfKii2UeqJH5fk3 ahUmNW9MEiYJcGXpEoxH =pbJr -----END PGP SIGNATURE-----
On Sat, May 17, 2014 at 2:40 PM, Roland Tapken <ml@lalamuhkuh.de> wrote:
Hi,
I'm using arch for about half a year on a few systems, but every time I install something from aur I'm asking myself one question:
Why is it considered dangerous to run makepkg as root?
My first guess was that the PKGBUILD usually comes from an untrusted source and may contain code to attack my system (copy personal data or install a rootkit or something like that). But on the other hand, this file tells makepkg how to build the package that will be installed as root, so if the author of the PKGBUILD has bad purposes he will just put that code into the created package.
The second idea is that this advice should prevent the script from *accidentally* damage my system. But this could be prevented by using fakeroot (which is disabled when calling makepkg with --asroot according to the manpage) or chroot. And actually the proper advice in this case should be to execute makepkg using a user dedicated for this, as for most arch users it would be worse if their personal file get deleted as if the system becomes unbootable.
Regards,
Roland
'--asroot' option has recently been removed. https://projects.archlinux.org/pacman.git/commit/?id=61ba5c961e4a3536c4bbf41...
On 2014-05-17 14:40, Roland Tapken wrote:
Hi,
I'm using arch for about half a year on a few systems, but every time I install something from aur I'm asking myself one question:
Why is it considered dangerous to run makepkg as root?
My first guess was that the PKGBUILD usually comes from an untrusted source and may contain code to attack my system (copy personal data or install a rootkit or something like that). But on the other hand, this file tells makepkg how to build the package that will be installed as root, so if the author of the PKGBUILD has bad purposes he will just put that code into the created package.
Maybe I've missed something reading through this thread, but *assuming* (yeah, I know) that packages can't run arbitrary scripts at install time (which I think is a valid assumption for pacman), there is a slight theoretical advantage to the current behavior in that if you never run $NEW_PACKAGE *as root* then your system cannot be compromised quite as extensively as if you had run PKGBUILD as root (which would allow completely arbitrary commands as root, either through a malicious PKGBUILD or other attack channels such as an exploitable gcc, etc.). Of course an attacker can still (via the build executables) delete all the files you actually care about ($HOME) or install trojans into your $HOME/bin (etc.), but still... If you discover such a comprosmise you'd "only" have to delete your $HOME and restore from backup[0], whereas a root compromise would require a full reinstall of everything. Regards, /b [0] Actually, there have been quite a few "local user -> root" exploits of the Linux kernel, so really you should wipe everything and reinstall from scratch anyway. Remember, I'm only speaking theoretically in the above.
Hi Bardur,
Maybe I've missed something reading through this thread, but *assuming* (yeah, I know) that packages can't run arbitrary scripts at install time (which I think is a valid assumption for pacman),
Is this so? I don't know since I've only scratched the surface of arch until now. But I'm not quite sure about this, since, for example, there must be a way to add new users like http after installing apache. How should this be done without a post-install-script?
Of course an attacker can still (via the build executables) delete all the files you actually care about ($HOME) or install trojans into your $HOME/bin (etc.), but still... If you discover such a comprosmise you'd "only" have to delete your $HOME and restore from backup[0], whereas a root compromise would require a full reinstall of everything.
Even if your assumption about pacman is correct: Just let the malicious PKGBUILD write a file into /etc/cron.d/, /etc/systemd or something like that and you're doomed. No need for privilege escalation. Regards, Roland
On 2014-05-17 21:50, Roland Tapken wrote:
Hi Bardur,
Maybe I've missed something reading through this thread, but *assuming* (yeah, I know) that packages can't run arbitrary scripts at install time (which I think is a valid assumption for pacman),
Is this so? I don't know since I've only scratched the surface of arch until now. But I'm not quite sure about this, since, for example, there must be a way to add new users like http after installing apache. How should this be done without a post-install-script?
I always thought that "this package needs users X,Y and Z" was handled via some metadata in the package description, not via scripts per se. Maybe I'm wrong on that too.
Of course an attacker can still (via the build executables) delete all the files you actually care about ($HOME) or install trojans into your $HOME/bin (etc.), but still... If you discover such a comprosmise you'd "only" have to delete your $HOME and restore from backup[0], whereas a root compromise would require a full reinstall of everything.
Even if your assumption about pacman is correct: Just let the malicious PKGBUILD write a file into /etc/cron.d/, /etc/systemd or something like that and you're doomed. No need for privilege escalation.
Ah, yes. True, of course. I knew I'd missed something! :) Regards,
On 2014-05-17 22:08, Bardur Arantsson wrote:
On 2014-05-17 21:50, Roland Tapken wrote:
Hi Bardur,
Even if your assumption about pacman is correct: Just let the malicious PKGBUILD write a file into /etc/cron.d/, /etc/systemd or something like that and you're doomed. No need for privilege escalation.
Ah, yes. True, of course. I knew I'd missed something! :)
Hm. Rethinking this I was going to say something about listing (and screening) all the files that a package *would* install, but it seems that it's not possible to list files installed by a package before installing it...? (pacman -Ql only accepts installed packages, apparently.) Regards,
在 2014-5-18，4:49，Bardur Arantsson <spam@scientician.net> 写道：
Hm. Rethinking this I was going to say something about listing (and screening) all the files that a package *would* install, but it seems that it's not possible to list files installed by a package before installing it...?
(pacman -Ql only accepts installed packages, apparently.)
Regards,
It is possible, try: tar tvf foo.pkg.tar.xz -- Regards, StarBrilliant
On 2014-05-17 15:49, Bardur Arantsson wrote:
On 2014-05-17 22:08, Bardur Arantsson wrote:
On 2014-05-17 21:50, Roland Tapken wrote:
Hi Bardur,
Even if your assumption about pacman is correct: Just let the malicious PKGBUILD write a file into /etc/cron.d/, /etc/systemd or something like that and you're doomed. No need for privilege escalation.
Ah, yes. True, of course. I knew I'd missed something! :)
Hm. Rethinking this I was going to say something about listing (and screening) all the files that a package *would* install, but it seems that it's not possible to list files installed by a package before installing it...?
(pacman -Ql only accepts installed packages, apparently.)
Regards,
Use the -p option, ie pacman -Qlp <packagefile>
On 05/17, Bardur Arantsson wrote:
On 2014-05-17 22:08, Bardur Arantsson wrote:
Hm. Rethinking this I was going to say something about listing (and screening) all the files that a package *would* install, but it seems that it's not possible to list files installed by a package before installing it...?
(pacman -Ql only accepts installed packages, apparently.)
'makepkg -o' downloads and unpacks the sources without building or installing them. -- "A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools." - Douglas Adams
Am 17.05.2014 22:08, schrieb Bardur Arantsson:
On 2014-05-17 21:50, Roland Tapken wrote:
Hi Bardur,
Maybe I've missed something reading through this thread, but *assuming* (yeah, I know) that packages can't run arbitrary scripts at install time (which I think is a valid assumption for pacman),
Is this so? I don't know since I've only scratched the surface of arch until now. But I'm not quite sure about this, since, for example, there must be a way to add new users like http after installing apache. How should this be done without a post-install-script?
I always thought that "this package needs users X,Y and Z" was handled via some metadata in the package description, not via scripts per se. Maybe I'm wrong on that too.
Such things are handled via install scripts[0], called by pacman when (un)installing/upgrading packages... and yes, packagers can put arbitrary code in there. (postfix exmaple[1])
Of course an attacker can still (via the build executables) delete all the files you actually care about ($HOME) or install trojans into your $HOME/bin (etc.), but still... If you discover such a comprosmise you'd "only" have to delete your $HOME and restore from backup[0], whereas a root compromise would require a full reinstall of everything.
Even if your assumption about pacman is correct: Just let the malicious PKGBUILD write a file into /etc/cron.d/, /etc/systemd or something like that and you're doomed. No need for privilege escalation.
Ah, yes. True, of course. I knew I'd missed something! :)
Regards,
[0] https://wiki.archlinux.org/index.php/PKGBUILD#install [1] https://projects.archlinux.org/svntogit/packages.git/tree/trunk/install?h=pa... Cheers
On 2014-05-17 22:55, ushi wrote:
Am 17.05.2014 22:08, schrieb Bardur Arantsson:
On 2014-05-17 21:50, Roland Tapken wrote:
Hi Bardur,
Maybe I've missed something reading through this thread, but *assuming* (yeah, I know) that packages can't run arbitrary scripts at install time (which I think is a valid assumption for pacman),
Is this so? I don't know since I've only scratched the surface of arch until now. But I'm not quite sure about this, since, for example, there must be a way to add new users like http after installing apache. How should this be done without a post-install-script?
I always thought that "this package needs users X,Y and Z" was handled via some metadata in the package description, not via scripts per se. Maybe I'm wrong on that too.
Such things are handled via install scripts[0], called by pacman when (un)installing/upgrading packages... and yes, packagers can put arbitrary code in there. (postfix exmaple[1])
I see. Good to know. The premise for my whole hypothetical was thus dismissed and I hang my head in shame ;). Regards,
On 17/05/14 03:12 PM, Bardur Arantsson wrote:
On 2014-05-17 14:40, Roland Tapken wrote:
Hi,
I'm using arch for about half a year on a few systems, but every time I install something from aur I'm asking myself one question:
Why is it considered dangerous to run makepkg as root?
My first guess was that the PKGBUILD usually comes from an untrusted source and may contain code to attack my system (copy personal data or install a rootkit or something like that). But on the other hand, this file tells makepkg how to build the package that will be installed as root, so if the author of the PKGBUILD has bad purposes he will just put that code into the created package.
Maybe I've missed something reading through this thread, but *assuming* (yeah, I know) that packages can't run arbitrary scripts at install time (which I think is a valid assumption for pacman), there is a slight theoretical advantage to the current behavior in that if you never run $NEW_PACKAGE *as root* then your system cannot be compromised quite as extensively as if you had run PKGBUILD as root (which would allow completely arbitrary commands as root, either through a malicious PKGBUILD or other attack channels such as an exploitable gcc, etc.).
Packages can and do run arbitrary code via the install script. This is used to do everything from adding new users / groups to regenerating caches / databases.
On Sat, May 17, 2014 at 5:40 AM, Roland Tapken <ml@lalamuhkuh.de> wrote:
My first guess was that the PKGBUILD usually comes from an untrusted source and may contain code to attack my system (copy personal data or install a rootkit or something like that).
I think that the point isn't that you're not supposed to run makepkg as root to protect against *malicious* packages, but rather to protect aganst *badly written* ones. There are of course many ways that a malicious package could get around that to hose your system, but a simple badly written package that spews files directly into /usr instead of into $pkgdir is easily thwarted by not having the permissions necessary to do so. Regards, ~Celti
participants (13)
-
Bardur Arantsson
-
Bigby James
-
BlissSam
-
Daniel Micay
-
Dimitris Zervas
-
Doug Newgard
-
Karol Blazewicz
-
Martti Kühne
-
Oon-Ee Ng
-
Patrick Burroughs (Celti)
-
Roland Tapken
-
ushi
-
William Giokas