Re: fakeroot a solution for multi-architecture building?
> As I understand it, only the changes file is pgp signed. Because this file
> contains md5 sums for the other "uploaded" files in the release, it acts
> to validate them as well. Once you have a valid, verifiable set what's the
> next step?
Well, I probably didn't explain myself properly. Let me try to describe
an attack.
We have machine a machine, say, called alpha-build, that is setup
to download newly uploaded source packages (probably build for i386)
from master.
alpha-build will of cource check the .dsc & .changes files, and
can be sure it has the proper source archive after it verified the
developper's pgp key. alpha-build will then happily build the
foo_0.0-0_alpha.deb file.
Now, for alpha-build to be able to create a foo_0.0-0_alpha.changes file
(and it has to do so, otherwise dinstall will not accept the upload),
alpha-build has to have some private key that is trusted by Guy's
dinstall. For the builds to be possible automatically, this private
key has to be available somewhere on alpha-build in plaintext[1].
Now comes the problem: alpha-builds' owners went away for the weekend
(say they went to a Linux congress in Aachen), and on friday evening
a bug in samba is announced on bugtraq. Unfortunately, alpha-build
has samba installed.
Now comes the (simple) attac: just exploit the samba bugs on alpha-build,
and you are now able to create packages that dinstall will trust.
(if alpha build can do it automatically, then surely someone who broke
root can do it). So, you simply remove those silly checks for pgp-correctness
of the developpers, and you make it create any package you like, that
does whatever you like, and let alpha-build sign it with the pgp key
that dinstall trusts, and let alpha-build upload it to master.
Realise, that this leaves virtually no traces to the intruder: s/he
probably broke into alpha-build via 20 other computers, all of
which have there logfiles erased. Nobody notices the compromise of
alpha-build untill it's owners come back from Aachen. And, by that
time there are probably already many people who have installed the
intruder packages.
At the moment, this is all not possible, as every package is signed
with a pgp key that is (hopefully) not in plaintext[1] form on some
computer. With the auto-build skeme it is.
Do I make myself now more clear?
> > Yes, the .tar.gz is authentic, but the .deb's cannot be (well, unless
> > you fully trust those machines).
>
> I'm not sure I'm following this argument correctly? What is there about
> "those" machines that would make them either trustworthy or not?
Basically: nothing. Just trust. Over this weekend, I wouldn't trust
any auto-build machines that had samba installed, for example. And,
in general, I'd probably say: the fewer /etc/inetd.conf entries
and daemons the machine has running, the more I trust it.
So, what's there to make a machine trustworthy? I guess, this
telinit 1
would do it for me. (rm /etc/inetd.conf would be optional, as I don't
think inetd is ran in single user mode).
[1] With plaintext I don't neccecerily mean that the pgp passphrase itself
is somewhere on the HD. But at least alpha-build _is_ able to
sign packages with the key, so the intruder can alpha-build make
sign any packages he likes.
--
joost witteveen, joostje@debian.org
#!/usr/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
#what's this? see http://www.dcs.ex.ac.uk/~aba/rsa/
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: