Is there any way to know if userland is patched?

Xin LI delphij at frontfree.net
Wed Nov 10 10:31:07 PST 2004


Hi, Julian,

On Wed, Nov 10, 2004 at 09:45:00AM -0800, Julian Elischer wrote:
> X-Sieve: CMU Sieve 2.2
> Date: Wed, 10 Nov 2004 09:45:00 -0800
> From: Julian Elischer <julian at elischer.org>
> User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8a3) Gecko/20041017
> X-Accept-Language: en, hu
> To: Xin LI <delphij at frontfree.net>
> Cc: freebsd-hackers at freebsd.org, freebsd-security at freebsd.org
> Subject: Re: Is there any way to know if userland is patched?
> In-Reply-To: <20041110173511.GA2940 at frontfree.net>
> X-Virus-Scanned: by amavisd-new at frontfree.net
> 
> Xin LI wrote:
[snip]
> I upgrade systems by creating packages which contain all upgraded files
> I have a set of makefiles etc. checked into my local CVS tree that check out
> a freeBSD tree at a given revision and build it (withlocal patches added)
> and then extracts out fies according to a list I supply. On completion I 
> check the list in too, so I can theoretically recreate that patch..

Hmm...  Thanks for the comments.  That's somewhat like the way I am currently
using at company.

We maintain a local CVS tree with a subset of ports/ tree as well as src/
tree containing some of our local changes.  The tree is has several frozen
branches that is maintained by a small group of staff, they make packages
for the upgrades.

For me, I think it might be beneficial if we can keep track of system patchlevel
in some other way that can be easily detected, so some ``guardian'' scripts
would be easier to create.

I have an idea that is somewhat too complex to be included in FreeBSD - we
maintain a ``master'' patchlevel, and two patchlevels indicating the least
``master'' patchlevel that touches kernel or userland.  It might be something
like this:

Master			| Userland		| Kernel
========================+=======================+=======================
4.10-RELEASE		| 4.10-RELEASE		| 4.10-RELEASE
4.10-RELEASE-p1		| 4.10-RELEASE		| 4.10-RELEASE-p1
4.10-RELEASE-p2		| 4.10-RELEASE		| 4.10-RELEASE-p2
4.10-RELEASE-p3		| 4.10-RELEASE-p3	| 4.10-RELEASE-p2

And propograte it somewhere.  This is somewhat complex as the security officer
must bump two version when he is doing a security update and I'm not sure whether
this is beneficial enough so I hesitate to proposal a patch of this, as I found
that Colin has a simpler solution in his excellent freebsd-update program, which
tracks binary changes by checking $FreeBSD$ changes.  While this is sometimes
not enough to detect every changes, but it requires less human interactions.

Cheers,
-- 
Xin LI <delphij frontfree net>	http://www.delphij.net/
See complete headers for GPG key and other information.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20041111/56bf8a34/attachment.bin


More information about the freebsd-hackers mailing list