oss-sec mailing list archives
Re: Check your pre/post install scripts in rpm/deb/... packages for security issues
From: Michael Orlitzky <michael () orlitzky com>
Date: Thu, 30 Apr 2020 08:35:28 -0400
On 4/30/20 7:21 AM, Johannes Segitz wrote:
In the long term we want to try if something like https://github.com/google/path-auditor can be used to automatically find these issues in our build systems. If you have measures in place to check for problems like these we would be interested to hear about them.
We have (had?) the same problem in Gentoo, http://michael.orlitzky.com/articles/end_root_chowning_now_%28make_pkg_postinst_great_again%29.xhtml The "solution" is basically To Not Do That. While some uses of chown/chmod/setfacl in post-install scripts are safe, we are fortunate that almost all of them are also mistakes. (A rare exception is if you need to fix some bad permissions set by an older version of the same package). Thus a `git grep chown` shows you a list of things that should probably be fixed, for one reason or another. Everyone else is on systemd now, but we still have this problem in our init scripts and our fake tmpfiles.d implementation as well: * https://github.com/OpenRC/openrc/issues/201 * https://github.com/OpenRC/opentmpfiles/issues/3 * https://github.com/OpenRC/opentmpfiles/issues/4 The root of the problem (ha ha) is that you shouldn't be doing things as root, especially in an automated fashion, on stuff you don't control. The Right Way To Do It is to create the top-most user-controlled directory as root, and give ownership of it to the unprivileged user. That's safe, since by my definition of "top-most" everything above it is writable only by root. After that, all remaining steps should be done *as the unprivileged user*, after dropping permissions. There are two missing tools here: 1. A portable tool to create directories with a given owner (like "install"), but that ensures the entire path up from the root of the filesystem to that directory is safe to operate in. 2. A portable tool to drop privileges. If those existed, we could ban chown, chmod, and friends from our packages and our init systems, forcing developers to use the safe alternatives.
Current thread:
- Check your pre/post install scripts in rpm/deb/... packages for security issues Johannes Segitz (Apr 30)
- Re: Check your pre/post install scripts in rpm/deb/... packages for security issues Michael Orlitzky (Apr 30)