On May 17, 2014 5:22:32 PM EEST, Roland Tapken 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

On 05/17, Dimitris Zervas wrote:

On May 17, 2014 5:22:32 PM EEST, Roland Tapken 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 05/18, Oon-Ee Ng wrote:

On Sun, May 18, 2014 at 12:57 AM, Bigby James wrote:

...

On 05/17, Dimitris Zervas wrote:

...

On May 17, 2014 5:22:32 PM EEST, Roland Tapken 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

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

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 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,

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>

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 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.