On Thu, 12 Jun 2008, Stanislav Brabec wrote:
Tom "spot" Callaway wrote:
On Thu, 2008-06-12 at 14:48 +0200, Jindrich Novy wrote:
Opinions?
One of the reasons why the mktemp option is appealing is because it is
not predictable, and helps lessen the security risks of knowing where
the buildroot is going to be and inserting malicious files.
This security problem exists from the early rpm versions and comes from
lines:
%install
rm -rf $RPM_BUILD_ROOT
mkdir -p $RPM_BUILD_ROOT
Anybody can use race condition to create more permissive directory.
That assumes "anybody" can create directories in the buildroot root, which
of course is the case with the now typical %{_tmppath}/%{name}....
buildroot. The situation is fairly different with the suggested
%{_topdir}/BUILDROOT/<something> buildroot as %{_topdir} is typically more
or less private: keep in mind that in rpm.org HEAD the default %{_topdir}
is defined as "%(echo $HOME)/rpmbuild" so unless overridden, it's "safe
ground".
Of course it's still possible to override the topdir to something that's
shared between different users, but it's still a different game from
current %{_tmppath} use: I wouldn't expect people to share their
%{_topdir} with malicious users (if they do, that's their headache).
Using mktemp() and keeping these lines in spec files will not improve
security in any way.
Yes, IF mktemp() is used in a shared directory such as /tmp or
/var/tmp. In the case of %{_topdir}/BUILDROOT/%{name}....XXXXXX it doesn't
really improve security either, it just ensures a fully clean buildroot
for a package (even if you forget to add the two lines at beginning of
%install, something that happens to me every now and then ;) and makes
sure packages are "buildroot clean", ie aren't playing dumb games with
hardcoded assumptions.
Whether those "advantages" are worth breaking --short-circuit I dunno - I
certainly use -bi --short-circuit all the time to test %install/%files
correctness and would miss it sorely. One possibility would be using a
non-predictable buildroot only for --rebuild but...
Secure build implies change of spec coding style. If rpmbuild itself
will do rmdir()+mkdir() safely (correct privileges, force fail if
directory exists and it is not possible to remove it), then the worst
problem with the static BuildRoot is a DoS. I think that local DoS on
rpmbuild is not a problem, because it already exists: one user adding
foo.spec to SPECS makes impossible to build foo by anybody else.
The "safe BuildRoot create" patch already exists in openSUSE.
Oh, I've somehow missed that entirely (I do every now and then look at
what distros are patching rpm with :), I'll have a look.
The only reason we use mktemp in there is because we couldn't make rpm
code changes to use the native glibc functions. As to rpm
--short-circuit, well, I honestly think we should think long and hard
about whether we want to keep it around.
If mktemp() would be preferred anyway, rpmbuild could store
package<->buildroot map in home directory. But I think, that it is an
overkill, as build directories and source directories are static.
Yeah, sounds like an overkill to me too.
- Panu -_______________________________________________
Rpm-maint mailing list
[email protected]
https://lists.rpm.org/mailman/listinfo/rpm-maint
