[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Today's i386 netinst (20051006): still secure apt failure



On Thursday 27 October 2005 19:02, Frans Pop wrote:
> I'll post the log of that chat later.

OK. Last action of the day for me.

Log attached. I've told mvo later about the update to base-installer and 
that I expected we'd get back to this discussion later; he asked to be 
kept in the loop.

I currently see 3 options:
- the patch to base-installer today magically works and we're happy
  with that
- change apt to also allow unauthenticated file: source lines
- get signed release files on CDs using a "debian-cd" signature; make
  sure that key is added to trusted keyring during base installation
  (mvo: easy using 'apt-key add')

There are some nice links/suggestions/tips in the log, so I think 
archiving it here is useful.

Cheers,
FJP
(Irrelevant trafic removed)
[17:03:21] <fjp> mvo: Could you have a look at http://lists.debian.org/debian-boot/2005/10/msg01270.html please and give your reaction?
[17:03:33] <fjp> mvo: re: secure apt and d-i
[17:11:04] <mvo> fjp: sorry for the lack, have you tried seting the option in /target/etc/apt/apt.conf.d/30allow-unauthenticated ?
[17:11:46] <mvo> fjp: and what about "apt-get -o APT::Authentication::TrustCDROM=True" ?
[17:12:18] <fjp> mvo: That's not the point... The point is that we don't use cdrom: at that stage, but file:
[17:12:37] <fjp> See the bottom part of the mail and the patch proposed in the follow up.
[17:13:35] <fjp> mvo: This is at the point in the installation where we run debootstrap. Configuring apt (and thus running apt-cdrom) only comes later.
[17:13:53] <fjp> mvo: I'm afraid that none of us realised this until now...
[17:14:34] <mvo> fjp: ok, I wasn't aware of this either
[17:14:58] <fjp> mvo: Well, we should have seen it, really :-P
[17:15:38] <fjp> Anyway, I feel this would not be a bad change as file: sources are also under the control of the user, much like cdrom: sources.
[17:16:09] <fjp> Though maybe the same option could be used for both.
[17:17:08] <moray> fjp: file sources aren't necessarily the user's own
[17:17:21] <moray> fjp: I used to get all my packages from the university's NFS server
[17:18:21] <fjp> moray: Yes, I'm aware of that. But they are more trusted than internet sources as they are internal to the organization.
[17:18:55] <moray> fjp: not necessarily, again, I think there still exist 'public' NFS servers
[17:19:22] <mvo> fjp: I don't really like adding more options like this. I wonder if we can't fix this differently
[17:19:40] <fjp> mvo: Suggestions very much welcome :-)
[17:19:45] <mvo> can't apt (in this stage) be run with --allow-unauthenticated?
[17:20:15] <moray> fjp: e.g. back then although I used the university one, I could also mount SunSITE machines over NFS
[17:20:17] <mvo> fjp: I don't really have intimate knowledge of the installer :)
[17:20:18] <fjp> That would be bad if you are installing from an internet mirror
[17:20:33] <mvo> right
[17:20:45] <fjp> Which is why joeyh has delayed implementing that. He sees that as a last resort.
[17:21:16] <fjp> I know that he feels that with secure apt available, d-i should make use of it.
[17:22:08] <mvo> yes, I think that's the right way (use apt-secure)
[17:22:15] <mvo> signed cds are not a option, right?
[17:23:09] <fjp> Well, I doubt we will get the archive key for that... Currently CDs are being built on a private server, not on a Debian machine.
[17:23:43] <fjp> It may be an option, but I don't think in the short run.
[17:23:44] <mrvn> fjp: I wrote a patch to apt to allow "deb [TRUSTED] ..." entries that skip gpg checking.
[17:23:59] <mrvn> fjp: exactly for such internal urls. see BTS
[17:23:59] <fjp> That would work.
[17:24:50] <mvo> mrvn: I'll have a close look to the patch now if it would solve the problem for the boot-team
[17:26:13] <fjp> We would have to parse the sources.list after apt-setup is run, but that can be done. The current config option is a bit more easy to implement.
[17:27:46] <mrvn> Why not just ship a gpg key and signed release file on the cd?
[17:28:07]  mvo likes this idea the most :)
[17:29:10] <mrvn> You would need some patching for DAK to get a signature by the official key or you create a special D-I key.
[17:29:39] <vorlon> can't be done in dak; dak doesn't build the Packages files for the CDs.
[17:30:00] <mrvn> Patch debootstrap to copy the key from the cd to /target/etc/apt/ and include gnupg.
[17:30:09] <mrvn> vorlon: it could.
[17:30:33] <mvo> fjp: what does joeyh think about the issue? does he think the additional "TrustedFILE" would be enough?
[17:30:37] <vorlon> mrvn: yay, blatantly false unsubstantiated assertions, more please.
[17:30:39] <mrvn> It wouldn't be the most flexible but it could.
[17:31:01] <fjp> mvo: Don't know. Haven't seen /spoken to him today.
[17:31:09] <vorlon> the only way that dak could do the signing is if dak subsumed debian-cd
[17:31:22] <Ganneff> mrvn: stupid thing. debian-cd needs to do it. not dak.
[17:31:34] <Ganneff> its just so completly wrong to think about dak for cd stuff.
[17:31:51] <mrvn> vorlon: Add a cron job that runs a grep-dctrl over the Packages file to get just the D-I debs and udebs and sign it. Pretty simple script to add.
[17:32:02] <Ganneff> mrvn: pretty useless
[17:32:07] <mrvn> Ganneff: does debian-cd have access to the key?
[17:32:09] <Ganneff> for like - real cds
[17:32:20] <Ganneff> mrvn: a debian-cd key, generated for that purpose, yes.
[17:32:27] <Ganneff> as they then generate it.
[17:32:30] <mrvn> Ganneff: that would be the B option.
[17:32:33] <Ganneff> distributed on that cd (public part)
[17:32:43] <Ganneff> mrvn: dak is not more than a Z option IMO.
[17:33:52] <mrvn> Would you do the final cd build with the release key then?
[17:34:06] <Ganneff> why?
[17:34:07] <mrvn> Or have 2 keys on the CD? The cd key and the archive key?
[17:34:09] <mvo> what's wrong with having two keys?
[17:34:11] <Ganneff> yes.
[17:34:27] <vorlon> the real solution is that debian-cd needs to support doing its own signing, and pushing the key into the install needs to be supported; but if there's not a secure environment where the signing can be done, it's no better than --allow-unauth.
[17:34:55] <vorlon> it's also not a very practical answer to the problem of getting a d-i beta out.
[17:35:11] <mrvn> I would think that cdimage.d.o (or where the CDs are build) is secure enough for the dailies.
[17:35:44] <vorlon> because I suppose in your world, no one ever installs a live system off dailies.
[17:35:45] <mrvn> fjp: There was also a patch to trust any CD media for apt.
[17:36:08] <Myon> what's wrong with trusting the debs on the CD?
[17:36:14] <Myon> you do trust the installer anyway
[17:36:14] <fjp> mrvn: Please read the mail I linked to at the start of this discussion first...
[17:36:39] <mrvn> vorlon: you already trust the buildds, the D-I daily build. How does trustung cdimage.d.o make it any more vulnerable?
[17:37:06] <mrvn> fjp: sorry, didn't see that since I droped in late. *backscroll*
[17:37:26] <fjp> mvo: I build an apt locally that had both my patch and both options: that resulted in a good install.
[17:37:43] <fjp> mrvn:  http://lists.debian.org/debian-boot/2005/10/msg01270.html
[17:37:58] <vorlon> Myon: there's nothing wrong with trusting the debs on the CD; that's already being done.  But "trusting the debs on the CD" != "trusting all debs signed by key $foo", and "trusting the debs on the CD" != "trusting the debs that are made available via bind mount in the chroot for installation purposes" (at least, in terms of apt configuration...)
[17:38:25] <vorlon> mrvn: "or wherever the CDs are built".
[17:38:40] <mvo> fjp: what after the system is installed? is the option still active on the instaled system? it must be for cdrom, but it is probably not needed for file)
[17:39:07] <fjp> mvo: No, we should delete that from the apt.conf. Agreed.
[17:39:50] <fjp> mvo: Could we do this as a short term solution and come back to it later?
[17:39:57] <mrvn> Can we use a cdrom url for the install?
[17:41:00] <fjp> Not sure if we could run apt-cdrom at that point...
[17:41:21] <mrvn> And what do you think about limiting keys to specific sources.list lines, as in maybe deb [4553452AF32D3E3453] ....?
[17:41:46] <mrvn> fjp: at the point the sources.list in chroot is used apt should be fully unpacked I think.
[17:44:24] <fjp> mrvn: testing that
[17:45:11] <mvo> fjp: I would like wait for joeyh and if he agrees, I will add it
[17:45:41] <mrvn> fjp: Patching debian-cd to actualy create a Release.gpg would be trivial as would adding the key on the cd. Patching debootstrap.udeb to include and configure it is probably the bigger problem.
[17:45:44] <mvo> I'm traveling right now, it may be a bit difficult to do uploads :/
[17:45:52] <fjp> mvo: OK. Just afraid that that will lose us yet another day...
[17:46:27] <fjp> mrvn: But getting that key integrated into the apt configuration is not...
[17:46:41] <mvo> fjp: no? apt-key add?
[17:47:15] <fjp> mvo: Did not know it was that simple :-P
[17:47:22] <mrvn> fjp: cp /cdrom/.disk/trusted.gpg /target/etc/apt/trusted.gpg
[17:47:39] <mvo> fjp: :) doing signed cds would be really nice
[17:47:47] <fjp> mrvn: Nice that would kill off the archive key.
[17:48:05] <mrvn> fjp: include it in the keyring.
[17:48:06] <mvo> fjp, mrvn: I'm having to leave now, be happy to talk to you later about this issue

Attachment: pgpLdQShvM2ab.pgp
Description: PGP signature


Reply to: