[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 30 Apr 2020 08:35:28 -0400
From: Michael Orlitzky <michael@...itzky.com>
To: oss-security@...ts.openwall.com
Subject: Re: Check your pre/post install scripts in rpm/deb/...
packages for security issues
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.
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
