inamerrata

Delays suck.

I’m actually skipping ahead here, I’d meant to blog about updating the dak codebase into shape for whatever changes were coming up first, but it turns out I’m not in the mood for that. Besides which, most of this entry is preprepared. In the last few entries we went over the background for updating our security infrastructure to make it possible to have security team members that don’t worry about vendor-sec issues (process, overview, NIv2 aka NINJA, queue-build issues), all the while skipping fairly lightly over the question of what has to actually happen. That happens to be the way I prefer to work, lots of background tinkering, then spend as little time on actual implementation as possible; it has it’s drawbacks, but hey, I like it.

Anyway, the second last step is working out in detail what’s going to happen. The delay in question was trying to get the security team to sign off on it, but unfortunately they’re busy enough that that looks like it’ll being an indefinite delay, so I’m going with the “well, ftpmaster maintains the dak/katie infrastructure for the security team, so in the end it’s our call on what’s best anyway” line of thought, and just plunging in. Fortunately the current and final plan should make pretty minimal changes to how the existing security team operate anyway, even assuming a massive testing security operation happening in parallel with them — so the downside risk is already pretty minimal. (And it was, afterall, developed in consultation with Joey, and then shopped around a few folks who’ve been doing security work for testing and kernels)

What is that plan, you may well ask. It’s something like this:

First, let’s restate the idea:

Concept

Allow two teams to exist, the current security team as the “vendor-sec subteam”, and the full team which can expand to also include the testing-security people and others interested and able to help out with security work but who do not have access to vendor-sec.

Then, we want to think about the processes that are involved at a global level. First for uploads that can’t be made public until some later date, and can only be worked on by the “vendor-sec” enabled security team.

• Source upload to queue/unchecked (as now)
  • Upload is authenticated etc
  • Upload is moved to queue/embargoed
• Upload is autobuilt
  • Logs are sent to a procmail address
  • Logs are forwarded (by procmail) onto the vendor-sec subteam
  • Logs are signed and sent back
  • Binaries are uploaded to queue/unchecked
  • Binaries are moved to queue/embargoed
• Uploads (source + binaries) are approved from queue/embargoed by
• running amber
  • Uploads are moved into the archive
  • The archive is mirrored
• The approver issues an advisory

And likewise for issues that don’t need so much secrecy:

• Source upload to queue/unchecked-disembargo (new directory)
  • Upload is authenticated etc
  • Source+version added to unembargo table
  • Upload is moved to queue/unembargoed
• Upload is autobuilt
  • Logs are sent to a procmail address
  • Logs are forwarded (by procmail, after checking unembargo table) onto the full team
  • Logs are signed and sent back
  • Binaries are uploaded to queue/unchecked
  • Noting that the source is in the unembargo table, Binaries are moved to queue/unembargoed
• Uploads (source + binaries) are approved from queue/unembargoed by running amber
  • Uploads are moved into the archive
  • The archive is mirrored
• The approver issues an advisory

Processes are great, but they have to be supported by proper information handling, so it’s worth looking at what the above actually means for the on-disk structures, too. This is particularly important, since filesystem level security is mostly how we wall off vendor-sec stuff from other users of the system (whether they’re also working on security issues, or doing, eg, web page maintenance or something equally random). Voila:

queue/unchecked, queue/unchecked-dismebargo
    world writable
    accessible only by katie
    contents automatically cleared every 15m

queue/embargoed
    writable only by katie
    accessible by vendor-sec subteam
    amber allows packages to be ACCEPTed
    [...] allows packages to be REJECTed

queue/unembargoed
    writable only by katie
    accessible by full team
    amber allows packages to be ACCEPTed
    [...] allows packages to be REJECTed

queue/accepted
    packages only sit in accepted briefly while amber is running

And finally, to sum things up, this is what a member of the security team should expect to actually do to release an advisory:

• Upload package to queue/unchecked (or queue/unchecked-disembargo)
• Wait for build logs to be sent to your address
• Check and sign those build logs
• Check the final packages in queue/embargoed (or queue/unembargoed)
• Run amber over the packages to accept them
• Fill in the template advisory generated and send it to the -announce list

The differences between that process and the current one used by the security team is pretty minor, ttbomk: currently uploads sit in queue/accepted not queue/embargoed, and currently the security team ignore the template advisories amber generates preferring to make their own — aiui, this is mostly due to delays in actually receiving the advisory template since amber mails it instead of leaving it somewhere convenient on disk.

Anyway, that’s what the plan looks like. We should see how well it survives contact with the enemy, or at least reality, remarkably soon.

(Of course, I guess “political issues” could always foul it up completely anyway, particularly going by the fact that it’s been more or less the only problem raised by the folks I’ve passed this on to… Oh well, reconstruct that bridge when we get to it, I guess)