freebsd security - Nov 2004 - Is there any way to know if userland is patched?

Dear folks,

I'm recently investigating large scale deployment and upgrading FreeBSD
RELEASE.  It's our tradition to bump "RELEASE-pN" after a security
patch
is applied, however, it seems that there is less method to determine
whether the userland is patched, which is somewhat important for large
site managements.

So is "uname -sr" the only way to differencate the patchlevel of a
security
branch?  I have read Colin's freebsd-update script and to my best of
knowledge this is the only way (and, on condition that we have re-compiled
the kernel and installed it, and reboot'ed).  Given the nature of a security
or errata branch, we can expect that no API/ABI changes will occour and it
should be safe to do make installworld/installkernel in any order, and bumping
patchlevel does not mean that a reboot must be done.

Please correct me if I was wrong, thanks.

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-security/attachments/20041111/2e799244/attachment.bin

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@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@frontfree.net>
> Cc: freebsd-hackers@freebsd.org, freebsd-security@freebsd.org
> Subject: Re: Is there any way to know if userland is patched?
> In-Reply-To: <20041110173511.GA2940@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-security/attachments/20041111/56bf8a34/attachment.bin

Xin LI wrote:
> Dear folks,
> 
> I'm recently investigating large scale deployment and upgrading FreeBSD
> RELEASE.  It's our tradition to bump "RELEASE-pN" after a
security patch
> is applied, however, it seems that there is less method to determine
> whether the userland is patched, which is somewhat important for large
> site managements.
> 
> So is "uname -sr" the only way to differencate the patchlevel of
a security
> branch?  I have read Colin's freebsd-update script and to my best of
> knowledge this is the only way (and, on condition that we have re-compiled
> the kernel and installed it, and reboot'ed).  Given the nature of a
security
> or errata branch, we can expect that no API/ABI changes will occour and it
> should be safe to do make installworld/installkernel in any order, and
bumping
> patchlevel does not mean that a reboot must be done.
> 
> Please correct me if I was wrong, thanks.
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..

I use the package system to keep track of which packages are loaded onto a 
system, and newer upgrade packages always have earlier ones as dependencies..
> 
> Cheers,