# Security update. Should be 8.1-RELEASE-p2?



## francis (Dec 13, 2010)

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;

```
REVISION="8.1"
BRANCH="RELEASE-p2"
```
 I was looking on the web and found FreeBSD 8.1 update to 8.1-p1

Thanks.


----------



## SirDice (Dec 13, 2010)

How did you do the update?


----------



## francis (Dec 13, 2010)

Because of GENERIC kernel, I used the *freebsd-update*. 
	
	



```
# 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)?


----------



## jrm@ (Dec 13, 2010)

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.


----------



## Nukama (Dec 13, 2010)

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.


----------



## junkie54 (Dec 13, 2010)

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" ?


----------



## phoenix (Dec 13, 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.


----------



## DutchDaemon (Dec 14, 2010)

Which, admittedly, is a bit of a sore spot in freebsd-update: the lack of easily accessible version information for the base install.


----------



## junkie54 (Dec 14, 2010)

*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?


----------



## DutchDaemon (Dec 14, 2010)

@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


----------



## francis (Dec 14, 2010)

So, when the next updates will touch the kernel, uname will show, finally, 8.1-RELEASE-p3?


----------



## DutchDaemon (Dec 14, 2010)

Basically: yes.


----------



## SirDice (Dec 14, 2010)

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.


----------



## phoenix (Dec 14, 2010)

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.


----------



## rbelk (Dec 15, 2010)

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.



That is actually a very good idea Phoenix. Post a PR for it.


----------



## junkie54 (Dec 15, 2010)

*phoenix, DutchDaemon*
Thanks.

Similar that the information on the version openssl is stored in a file 
	
	



```
/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?


----------



## SirDice (Dec 15, 2010)

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*.


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.


----------



## DutchDaemon (Dec 15, 2010)

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)


----------



## SirDice (Dec 15, 2010)

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.


----------



## rbelk (Dec 15, 2010)

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.



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?


----------



## SirDice (Dec 15, 2010)

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


----------



## AndyUKG (Dec 15, 2010)

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.


----------



## SirDice (Dec 15, 2010)

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).


That's what I suggested in post #15


----------



## AndyUKG (Dec 15, 2010)

SirDice said:
			
		

> That's what I suggested in post #15



Ah, sorry hehe, then I agree with you!


----------



## DutchDaemon (Dec 15, 2010)

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?


----------



## AndyUKG (Dec 15, 2010)

DutchDaemon said:
			
		

> Wouldn't that kernel replacement require a reboot to show the new version in uname, though?



It would I suppose, although you could always live without that knowing that it won't be updated until you reboot. Or my other suggestion, that freebsd-update will at least tell you that uname will report the wrong version unless you recompile the kernel. Or completely remove the pX version from the uname info, because it isn't compatible with binary OS updates a la freebsd-update?


----------



## mfaridi (Dec 20, 2010)

*after run freebsd-update fetch and install*

[ thread merged in - Mod. ] 

I use FreeBSD 8.1-RELEASE with Generic Kernel and AMD64 version , after run these command for fix security risk 

```
freebsd-update fetch && freebsd-update install
```
I reboot system and when I run uname -a I see this 

```
FreeBSD mfaridipc.faridi 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Mon Jul 19 02:36:49 UTC 2010     root@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  amd64
```
and I see my FreeBSD is Release and I do not see something like 
	
	



```
p1
```
 or 
	
	



```
p2
```
I think I must see something like this

```
FreeBSD mfaridipc.faridi 8.1-RELEASE-p2 FreeBSD 8.1-RELEASE-p2 #0: Mon Jul 19 02:36:49 UTC 2010     root@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  amd64
```
Am I right ?


----------



## hedgehog (Dec 20, 2010)

AFAIK p1 and p2 security patches didn't touched kernel, so uname output was unchanged


----------



## graudeejs (Dec 20, 2010)

hedgehog said:
			
		

> AFAIK p1 and p2 security patches didn't touched kernel, so uname output was unchanged



Exactly.


----------



## SirDice (Dec 20, 2010)

DutchDaemon said:
			
		

> Wouldn't that kernel replacement require a reboot to show the new version in uname, though?


True.



> Not something production server admins are particularly fond of, especially if it's just for getting base system version information right.


Admins shouldn't be afraid to reboot their systems, uptime is highly overrated. If the service you are providing doesn't allow for downtime (even scheduled downtime) you should be using some fail-over or high availability solution.


----------



## DutchDaemon (Dec 20, 2010)

Let the record show that I am weary of uptimes > 1 month myself. I was talking more about the 'change management mafia' that cannot admin a server without an Excel spreadsheet containing their tickets.


----------



## SirDice (Dec 20, 2010)

DutchDaemon said:
			
		

> I was talking more about the 'change management mafia' that cannot admin a server without an Excel spreadsheet containing their tickets.


Ah, the joys of ITIL and a corporation that treats it like it's the only true way of doing things. So you end up spending 3 hours doing all sorts of administrative crap for a change that only takes 10 minutes to implement x(


----------



## rbelk (Dec 20, 2010)

SirDice said:
			
		

> Ah, the joys of ITIL and a corporation that treats it like it's the only true way of doing things. So you end up spending 3 hours doing all sorts of administrative crap for a change that only takes 10 minutes to implement x(



Sirdice, ITIL does provide a pre-approved maintenance window. We use it where I work.


----------



## DutchDaemon (Dec 21, 2010)

We sympathize, I'm sure.


----------



## SirDice (Dec 21, 2010)

rbelk said:
			
		

> Sirdice, ITIL does provide a pre-approved maintenance window. We use it where I work.



Sure. Unfortunately about 99% of my work doesn't fall into that category


----------



## francis (Dec 21, 2010)

But if I update FreeBSD via via a source code patch, as it is described here (*SA-10:10.openssl*), uname will show p2, right?


----------



## SirDice (Dec 21, 2010)

francis said:
			
		

> But if I update FreeBSD via via a source code patch, as it is described here (*SA-10:10.openssl*), uname will show p2, right?



No, the patch only rebuilds libssl not the kernel.


----------



## francis (Dec 21, 2010)

OK, now everything is really clear. 
Now I have to wait for version 8.2, and using *freebsd-update* utility to upgrade 8.1 to 8.2. 
I have one more question; Often this method fails? I mean the attempt failed updates i.e. from 8.0 to 8.1. I ask because I never did a binary upgrade. I always installed the new release from CD, but never update. This time I want to do update. Is there anybody who failed update using *freebsd-update* utility?


----------



## SirDice (Dec 21, 2010)

Search the forum, there were some people who did have problems. 
But on the other hand, people that don't have problems won't post here


----------



## jgh@ (Jan 1, 2011)

I believe you could easily overwrite the variable though by editing /etc/sysctl.conf 
Another way to do it would be to have the kernel redistributed with the correct patch level on every update. (discussed in #bsdports) Not ideal, however it couldn't be changed in any way.


----------

