--DiL7RhKs8rK9YGuF
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

* Hubert Feyrer writes:
> On Sat, 22 Jan 2005, Mark Weinem wrote:
> >>	http://plastictree.net/software/sepbuild/index.html
> >
> >The site has know an abstract:
> >
> >	"sepbuild is a package for separating builds.
> >
> >	A separating build is a build of a (possibly large) number of
> >	packages in such a way that there is a minimum influence among
> >	the packages. This reduces the impact a trojaned or malicious
> >	package might have on other packages. This reduction can be
> >	considerably large.
>=20
> How is this different to a bulk build in a chroot environment (which we=
=20
> already have, see=20
> http://www.netbsd.org/Documentation/pkgsrc/binary.html#bulkbuild)?

Doing a bulk build (in the usual way) in a chroot leads to a separation of =
the=20
build from the rest of the system. This is fine. However, it does not intro=
duce=20
separation _among_ the built packages. As far as I know, bulk builds (in th=
e=20
ususal way) allow (and most often require) that code from the distfiles is=
=20
executed with root permissions. If now a certain distfile has been trojaned=
,=20
this can compromise _all_ built packages. The same can happen even if you s=
tart=20
the build as a non-root user, because then all installed files as well as t=
he=20
binary packages are writable by this user.

sepbuild minimizes the possible influences among the packages. Currently, i=
t is=20
like that:

IF you would like to trust package A, THEN you have to trust all other pack=
ages=20
from that build.

With sepbuild, it is like that:

IF you would like to trust package A, THEN you have to trust all other pack=
ages=20
ON WHICH PACKAGE A DEPENDS.

This can make a considerable difference. Just consider your favourite edito=
r. =20
Of course, you have to trust this program. Now consider some instant-messag=
ing=20
program that you use once in a while but for nothing important. Then, there=
=20
likely is no need to trust it. However, with bulk builds (as they are now) =
you=20
also have to trust the instant-messaging program if you would like to trust=
=20
your editor! With sepbuild, you only have to trust the editor and all packa=
ge=20
that it depends on. (Provided that you also separate the editor from the=20
instant-messaging program during runtime. This can be done by using differe=
nt=20
accounts, see http://plastictree.net/software/privsep).

If you would like to have a similar separation with chrooted non-root bulk=
=20
builds (in the usual way), then you would have to start a completely new bu=
ild=20
for each package. This will have the same effect, but takes much more time.=
 (It=20
could be optimized by first building libraries this way and then using thei=
r=20
binary packages to populate the chroot environment before a package which i=
s=20
dependent on them is built.)

--=20
Lasse Kliemann
      private homepage: http://plastictree.net
   NO software patents: http://swpat.ffii.org
do NOT use M$ products: http://plastictree.net/articles/noms

--DiL7RhKs8rK9YGuF
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (NetBSD)

iD8DBQFB8osw1gObwed86AkRAkiEAKCAklVJiqi8jk30pBS4dlHWntEvFgCglqHk
vHsSEe4ltHasJcVclQzlE8M=
=CAt+
-----END PGP SIGNATURE-----

--DiL7RhKs8rK9YGuF--