Date: Fri, 19 Oct 2001 06:14:51 +0200 (IST) From: Yonatan Bokovza <yonatan@jamus.xpert.com> To: <binup@freebsd.org> Subject: design issues [3 frags left] (long) Message-ID: <Pine.LNX.4.33.0110190610300.4537-100000@jamus.xpert.com>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.33.0110190610300.4537-100000>