Security update. Should be 8.1-RELEASE-p2?

francis

francis

Hi all, I'm using FreeBSD 8.1-RELEASE, and I have problems(?) with security updates. When there is a new SA, I am running the freebsd-update/install because of GENERIC kernel. Everything seems okay, but after reboot, uname -a command shows that there is not p2. I had similar problem with the update when it should be p1 (FreeBSD-SA-10:08.bzip2.)

Is it normal, that uname does not show patch level (pX)? /usr/src/sys/conf/newvers.sh file contains;
Code: 
REVISION="8.1"
BRANCH="RELEASE-p2"
I was looking on the web and found FreeBSD 8.1 update to 8.1-p1

Thanks.
 
Because of GENERIC kernel, I used the freebsd-update.
Code: 
# freebsd-update fetch ===>>>  list of files to change
# freebsd-update install
# shutdown -r now / or even reboot
But after reboot, uname still show 8.1-RELEASE #0. Should not be a p2 (last SA-10:10.openssl)?
 
When you run freebsd-update, but don't compile a new kernel, uname -a will still show the old patch level (e.g. 8.0-RELEASE-p2 instead of 8.0-RELEASE-p3). To see the patch level take a look at /usr/src/sys/conf/newvers.sh.
 
There were updates to openssl and bzip2 since the 8.1-RELEASE, which are not part of the kernel.
The kernel is not affected by this updates, so the kernel shows the "old" version. (i.e. 8.1-RELEASE)

[CMD=""]uname -a[/CMD] shows "-pX" after reboot, if there is a change in the kernel, or you've compiled the kernel from sources.
 
I am too use the "freebsd-update fetch" and "freebsd-update install" to upgrade openssl (FreeBSD 8.1-RELEASE, GENERIC kernel), but I do not understand why "openssl version" anyway say "0.9.8n 24 Mar 2010" ?
 
uname shows version information of the kernel.

freebsd-update does binary patching, thus only updating the bits that have changed.

If the update doesn't include patches for the kernel ... the kernel version info doesn't change. Hence, an update to openssl, done via freebsd-update, won't touch the kernel, and the version info (via uname) won't change.
 
Which, admittedly, is a bit of a sore spot in freebsd-update: the lack of easily accessible version information for the base install.
 
phoenix
Thanks for the clarification, but I was talking about "openssl version" instead of "uname".

DutchDaemon
Means using the binary update can not rely on the reports of updated versions of the components (for example "openssl version"), but how to check the openssl updated or not? Just check the file dates /usr/lib/libssl.a /usr/lib/libssl.so?
 
@junkie54: The freebsd-update fetch command prints what it's replacing (or going to replace), so you could hang on to those. Other than that, in the case of specific base-system applications like openssl, it comes down to running the correct command to get version information, like [cmd=]openssl version[/cmd]

And more in general: when I wrote 'version information for the base install', I meant a general version number for the total base system as a whole, as installed/update by freebsd-update. It would be nice to have e.g. a uname -w command to signify the 'world version' as opposed to the 'kernel version'. Those who, like me, build the world from sources obtained through svn have it easier with their detailed revision numbers when checking out the source tree ;)
 
One way to solve it for freebsd-update would be to always replace the kernel too. The drawback of that is obviously that you have to download and install something merely to have a version number updated. Not ideal but it could work.
 
A better way to solve it would be to introduce a new sysctl along the lines of os.version that would include the OS version, patch level, etc, that could be updated separately from the existing kern.version.

Feel free to implement it. :) I'm anything but a C coder.
 
phoenix said:
A better way to solve it would be to introduce a new sysctl along the lines of os.version that would include the OS version, patch level, etc, that could be updated separately from the existing kern.version.

Feel free to implement it. :) I'm anything but a C coder.
Click to expand...

That is actually a very good idea Phoenix. Post a PR for it.
 
phoenix, DutchDaemon
Thanks.

Similar that the information on the version openssl is stored in a file
Code: 
/usr/bin/openssl
and it wasn't updated (it and isn't present in the list "freebsd-update fetch"), therefore [cmd=]openssl version[/cmd] shows the old version. However I think it would be logical to update and this file, let and only to see the version.

Or there can be at all after binary updating a version openssl has changed, and a problem only at me?
 
phoenix said:
A better way to solve it would be to introduce a new sysctl along the lines of os.version that would include the OS version, patch level, etc, that could be updated separately from the existing kern.version.
Click to expand...
I'm not sure this is going to work. Sysctls are implemented in the kernel. So to change os.version it would still require a kernel change.
 
No, you're overthinking this: freebsd-update install will simply echo a new sysctl value >> /etc/sysctl.conf ;)

(don't be surprised when someone actually implements this)
 
Yes, thought of that too. What's stopping some other process from modifying the sysctl in /etc/sysctl.conf? You basically cannot trust that information because it's user editable.
 
SirDice said:
Yes, thought of that too. What's stopping some other process from modifying the sysctl in /etc/sysctl.conf? You basically cannot trust that information because it's user editable.
Click to expand...

That's true SireDice. A better way would be to have a loadable module called version.ko. You could then have a signed file in /etc that stores the data. When an update is applied the freebsd-update utility updates that file. Then when you did a "sysctl kern.version" you would get the appropriate version.

Did I just do the project summary?
 
Better but I still see some problems with that, the kernel module would need to be unloaded and loaded again for one. Second problem is that kernel modules aren't build when doing a buildworld because they are part of the kernel. I do like the idea of a signed file in /etc/ though. But this will pose problems for people who do a source update. They can't sign it unless the private key is known. When the private key is known to the build system it can be recovered which completely invalidates the trust.

Tricky stuff :e
 
Hi,

Where an update does not touch the kernel, and therefore the kernel is not updated by freebsd-update, which causes this confusion of uname not showing the correct info. Isn't the obvious solution, that the kernel is always included in freebsd-updates even when its not actually updated itself? Obviously the downside is that this is wasteful in terms of people downloading a new kernel where its not actually changed (other than the version number). But I don't think we are talking about a huge file size either, isn't it worth the extra 10MB (or would it be more than that?) on the rare occasion when the kernel has no updates?
Would save a lot of confusion...

Alternatively freebsd-update could at least advise you of this issue in these cases, ie "if you do not recompile your kernel uname will continue to show version X"

ta Andy.
 
AndyUKG said:
Where an update does not touch the kernel, and therefore the kernel is not updated by freebsd-update, which causes this confusion of uname not showing the correct info. Isn't the obvious solution, that the kernel is always included in freebsd-updates even when its not actually updated itself? Obviously the downside is that this is wasteful in terms of people downloading a new kernel where its not actually changed (other than the version number).
Click to expand...
That's what I suggested in post #15 ;)
 
Wouldn't that kernel replacement require a reboot to show the new version in uname, though? Not something production server admins are particularly fond of, especially if it's just for getting base system version information right. I'm not currently using freebsd-update myself, but I'm assuming that a non-kernel patch cycle will not require a reboot?
 
You must log in or register to reply here.
Back
Top