From owner-freebsd-binup Thu Oct 18 20:13: 1 2001 Delivered-To: freebsd-binup@freebsd.org Received: from jamus.xpert.com (jamus.xpert.com [199.203.132.17]) by hub.freebsd.org (Postfix) with ESMTP id EB2D037B4CF for ; Thu, 18 Oct 2001 20:12:37 -0700 (PDT) Received: from yonatan (helo=localhost) by jamus.xpert.com with local-esmtp (Exim 3.22 #1) id 15uR3b-0001Bk-00 for binup@freebsd.org; Fri, 19 Oct 2001 06:14:51 +0200 Date: Fri, 19 Oct 2001 06:14:51 +0200 (IST) From: Yonatan Bokovza To: Subject: design issues [3 frags left] (long) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-binup@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, I'd like to throw upon y'all this opinion before we proceed any further with the development. Please, this topic is highly bikeshadeable. Don't! Lets take a step back and see what is it we're trying to accomplish: (Or as I often say to my clients "First we define optimal, then we get there"). There are several times in the lifespan of a server where it _must_ communicate with other parties (downloading files from the Internet, cp-ing tarballs to /usr/ports/distfiles etc...) : 1. Complete OS upgrade. The equal, in FreeBSD, of cvsupping "stable", building and installing the world and the kernel. Does not occur very often on stable-production servers. Occurs much more often on development or DeskTop installations. cvsup handles that. 2. 3rd party software installations. After a fresh install, we usually want our server to actually do something, run a web service, DNS, mail or alike. These 3rd party software, as well as assorted tools for maintenance are what we refer to in this section. Being that this section is the only one dedicated to 3rd party software, the topic of upgrading it also falls in this category (upgrading apache-1.3.9 to 1.3.22, but not 4.4-Release to -Stable or the next -Release). Our ports/packages handles that, with the help of cvsup to update the ports tree. (I'm not familiar with BSDPAN, please include a link to more data in your reply.) 3. Security patches. Ideally, this is the only updates a server receives between major updates of the server-software or the operating-system-software. This is a small batch of data, that's important to apply fast. These are handled manually. (Yes, I know the patches are incorporated into -stable and updates in the ports tree. But no sane sysadmin will rebuild he's world to patch "ls". Same for ports, no sane admin will install a new version of stable and running server if he can get away with a small patch, small build and small reinstall.) Security Requirements for all modes: Authentication, of parties: Those files are _really_ from cvsup1.freebsd.org and not from cvsup1.badguys.org . Authentication, of data: Those are _really_ the files I requested. _not_ confidentiality: that's the facet meaning "no one can understand what's this data I'm downloading from cvsup[1-16].freebsd.org . The only two important bits we need to know about the data is that it's right (no tampering) and that we're taking it from the right place (no server/session spoofing/hijacking). Typical systems: The server-ish environment I was referring to before is one example of an archetypical system. Low maintenance is the key here. Like, installing release, upgrading server-software on important occasions, installing relevant security patches on the fly, and installing the next release again. Suppose our FreeBSD system will end up linux-ish (pardon..), in the sense that it will consist of a kernel and additional packages. Maybe one package will not be optional as it requires for the installment of the kernel and the other packages (i.e. gcc, ln, bourne-shell, make, the static-bins... ). Or we have a DeskTop-like machine, where the worldly updates are common, and 3rd party packages are installed and deinstalled on a daily basis. Data analysis: What data do we need, where is it stored, what's the security features it needs, and where does it goes too. Define "server"= Several designated servers that serves the entire userbase. cvsup[1-16].freebsd.org (for example). Define "client"= A machine running FreeBSD that utilize out binary updater. Looking at the server is (almost) simple, This is the data the server needs to hold: Unique data: A. Proof of the server's identity (for authentication). B. [Optionally] Mirror of all the packages binaries/tarballs. Single package metadata: 1. General options. 2. [Optionally] Metadata authentication. For every binary needed to install: 3. Mirrors for this binary. 4. authentication data (we'll talk about why it needs to be stored instead of generated- later). 5. [Optionally] Patches for this binary (if it's in a tarball of it's own, have another record for mirrors and authentication data. Optionally: 6. Multiple versions of all of the above (sorted by version or date). That's all I can think of when it comes to the server. Let's go over each and every part and explain: The sharper reader probably noticed the solution I'm going to offer will require server authentication, hence digital-signing capabilities. I'll even jump the wagon and say PKI and CA and X509.V3. Unique: The proof of the server's identity [A] should (in this solution), be kept secret and used to sign data to prove the server originated it. This is an elaborate scheme and need further thought and I'd be happy to hear of better options. [B] might be used to verify to the client that the metadata he's receiving is real. We have no assurance, today, that the data we cvsup is untouched. This should change, and the ideal way (TMHO) is that the updating procedure (the downloading of package metadata) will also be secure. package: [1] will hold the nomenclature (category/name), version, the dependencies, flags (like BROKEN) maybe a list of installed files. A cool feature would be to take note (like, size+date+time or signature) of the files as they are installed, and verbosely not remove any file that changes. This will stop "deinstallation" from removing config files. But that's for later. An important thing that's stored in here are references to security patches. The client should be able to ask "Are there any security patches for asd-1.2_3 ?" and the server should be able to answer "NO" or "yes, it's patch-cc". Anyone can think of a better scheme to maintaining patches in separate from the main tree? [2] This is very similar to out current md5 signatures stored in distfiles, only it will be used to authenticate the patched and the rest of the metadata. [3] again, like today, is list of pointers to the rest of the world. [4] could be incorporated in the previous [2]. The point of this one is to assure the safe transfer of our binary from the mirror to it's destination, like today's distfiles md5 signature. [5] are today's patch-??. No need to elaborate on this one. [6] if stuff wasn't complex enough, we could evade erasing any thing we do and allow clients to request packages by date/version, and not only the newest. Let's take a look at the client: The singular data the client holds: Preknowledge of the servers identity (i.e. certificate footprint). The client must hold two, maybe intersecting, databases: A. Database of all the most update packages, consisting of: 1. General options. For every binary needed to install: 2. [Optionally] Patches for this binary (if it's in a tarball of it's own, have another record for mirrors and authentication data. 3. Mirrors for this binary. B. database of installed packages. 1. General options. 2. xref to [A] for the purpose of updating the package. Note the client holds no "Authentication data" but the minimum reqd. to assure the server's identity and signatures. Elaborating: [A] First and foremost, we should consider installments where this database does not exist. Production servers should have no use for it. Maybe the solution would be to install binary packages. This is the equivalent of today's ports tree. [B] This is the only database in the system which I don't like the idea of it being public. Call me paranoid, but I prefer my users not having such an easy access to find out what's installed and what version is it. This data is most crucial when planning an attack. That's also the reason I wouldn't want [A] on my servers- there's no need for it to be there, once we're running. Oh well, maybe just "wheel" members. The system I designed here shares many things in common with the ports tree and the packaging system. The updating of the security-patches has it's tweak. That means we're left with finding a solution for the "complete OS upgrade". Maybe defining the kernel and the "world" as packages with huge sources tarball... K, it's nearing 05:00 and I should _really_ get some sleep. Blame any logical faults and spelling errors on this time of night. P.S. That's my way of saying "I'm on this list too". :-) Yonatan Bokovza To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-binup" in the body of the message