The same thing you mention about Debian is being done in FreeBSD-stable. They too have started to get the OpenSSH-3.3/3.4 in the base ASAP. They were told (by Theo) to upgrade or turn sshd off altogether.
Getting the privsep feature into the base system's OpenSSH is a good thing surely, but certainly not a requirement to deal with this vulnerability. As a matter of fact, the OpenSSH-2.9 (with backported security patches) used in -stable now and distributed with 4.6-RELEASE turns out to be not vulnerable at all.
There was a lot of discussion on the FreeBSD mailing lists, you may call it the "Theo show" with comments of the maestro himself. Check the mailing lists archives at freebsd.org (if updated already).
Unfortunately, for FreeBSD-stable this means that they'll have to jump versions to openssh-3.3 most likely by using the openssh-portable port and introducing that into the base distribution. Work is already being done (notably by DES, one of the commiters, hats off!)
Some people advised getting rid of the default openssh and installing the newer one through ports. Trouble is that the functionality that "separates privileges" is relatively new and has to be incorperated into -stable quickly now.
Many people didn't like this especially because Theo's comments seem to indicate that the required fix in question is small and simple.
And the new feature in openssh may only be *one* way to prevent said exploit from causing serious harm. That's something entirely different from an actual fix of course. So some folks felt that they were being dragged into a major version bump maybe unnescessary.
Consider for example that OpenBSD doesn't use PAM while FreeBSD does use it (extensively), and you can imagine a bumpy ride on -stable soon.
I don't mean to take sides or something, just let you know what's going on.
Where's that anti-troll I saw the other week? It had the *BSD is dying text with suitable wordwrap and then altered to show the silhouet of Beastie in the text. It was.. well.. refreshing.
Mach kernel, BSD userland... but the guy was a nitpicker (sp?) anyway. Probably reads/. hehe
Re:Not trying to start a Holy War
on
FreeBSD 4.6
·
· Score: 1
Yep that's true. But I've still put FreeBSD (4.x) on the server I'm setting up. SMP at least works, in the sense that it will devide processes over processors (I only have 2 procs BTW), but it's not grannual yet in the sense that it subdivides that into, say, threads.
5.0 (currently the unstable tree) will have much better SMP support. But at least for now I can use my 2nd processor all the way. It's just that the extra performance gain that is possible by having 2 or more processors with a fine-grained management isn't there just yet in -stable.
I tend to see this as something to be made better rather than as something that decreases performance though.
Re:Not a zoo. Linux is good enough
on
FreeBSD 4.6
·
· Score: 1
You are *absolutely* right. But the same argument could be made vice versa... I know and like BSD, I can do the same as with Linux... so why would I need Linux. Both are OK. I switched Debian -> fBSD mostly out of emotional reasons (Specifically: the KDE packages maintainer being yelled at by lazy nogoods for not being fast enough in providing packages while it even was a non-official side project. That really disgusted me.)
And, possibly because I was still newbie enough to get into something new, I happened to like the somewhat hardcore but very straightforward and consistant way of configuring a BSD system.
I think I could have landed at Slack just as easily though.
Hmm.. wouldn't you like to make sure that your userland comes up OK too? It's going to be a PITA if it turns out it doesnt but only after you reboot the box... 30 days later...
Well, there's surely going to be some 4.7 vs 5.0 vs 4.8 confusion by then to add some spice to it:)
Re:warning: corrupt ISOs
on
FreeBSD 4.6
·
· Score: 1
Yesterday I read an online piece somewhere (sorry no URL), that mentioned that Murray was at some conference (delay reason #1) and that one of the ISOs apparently was b0rked thus there had to be an update along the mirrors (delay reason #2). This would have caused the last 1-2 days of extra delay. Though frankly, it may also have been hearsay.
Before that and after the 4.6-REL tagging took place it was a matter of compiling packages, putting ISOs together, etc. This part is all normal practice AFAIK and it's not unusual if it takes a week longer or so than anticipated.
As the person before me said, many linux apps just run straight away through the linux compat layer. The other week I downloaded the new RealOne player (aka realplayer9) linux version (tagged as alpha), just installed it in its own directory under/usr/local and what-da-you-know.. it just worked.
Linux compat is basically a set of RedHat rpms, and some layer over the BSD kernel that makes it able to talk with apps that expect a linux kernel. We had linux-6.1 and now we have 7.1. This refers to the RH version numbers.
Slashdot Mirror
Find a toilet paper manufacturer visionary enough to enrich their product with a weekly /. hardcopy.
After all... everyone has one.
.. and one word came up... WHORE.
I agree, and IIS' early disclosure may have been provoked by this (not that I have a lot of respect for their behaviour lately).
The same thing you mention about Debian is being done in FreeBSD-stable. They too have started to get the OpenSSH-3.3/3.4 in the base ASAP. They were told (by Theo) to upgrade or turn sshd off altogether.
Getting the privsep feature into the base system's OpenSSH is a good thing surely, but certainly not a requirement to deal with this vulnerability. As a matter of fact, the OpenSSH-2.9 (with backported security patches) used in -stable now and distributed with 4.6-RELEASE turns out to be not vulnerable at all.
Unfortunately, for FreeBSD-stable this means that they'll have to jump versions to openssh-3.3 most likely by using the openssh-portable port and introducing that into the base distribution. Work is already being done (notably by DES, one of the commiters, hats off!)
Some people advised getting rid of the default openssh and installing the newer one through ports. Trouble is that the functionality that "separates privileges" is relatively new and has to be incorperated into -stable quickly now.
Many people didn't like this especially because Theo's comments seem to indicate that the required fix in question is small and simple. And the new feature in openssh may only be *one* way to prevent said exploit from causing serious harm. That's something entirely different from an actual fix of course. So some folks felt that they were being dragged into a major version bump maybe unnescessary.
Consider for example that OpenBSD doesn't use PAM while FreeBSD does use it (extensively), and you can imagine a bumpy ride on -stable soon.
I don't mean to take sides or something, just let you know what's going on.
Capability-based rather than owner-based permissions.
yeah by pigeon :) Luckily it was at close range or we'd been here for weeks...
Where's that anti-troll I saw the other week? It had the *BSD is dying text with suitable wordwrap and then altered to show the silhouet of Beastie in the text. It was.. well.. refreshing.
Mach kernel, BSD userland... but the guy was a nitpicker (sp?) anyway. Probably reads /. hehe
5.0 (currently the unstable tree) will have much better SMP support. But at least for now I can use my 2nd processor all the way. It's just that the extra performance gain that is possible by having 2 or more processors with a fine-grained management isn't there just yet in -stable.
I tend to see this as something to be made better rather than as something that decreases performance though.
And, possibly because I was still newbie enough to get into something new, I happened to like the somewhat hardcore but very straightforward and consistant way of configuring a BSD system.
I think I could have landed at Slack just as easily though.
See mount_msdos(8). BTW, you don't mount a partition, you mount a filesystem.
Hmm.. wouldn't you like to make sure that your userland comes up OK too? It's going to be a PITA if it turns out it doesnt but only after you reboot the box... 30 days later...
This is wrong. Read the damn handbook.
Well, there's surely going to be some 4.7 vs 5.0 vs 4.8 confusion by then to add some spice to it :)
Before that and after the 4.6-REL tagging took place it was a matter of compiling packages, putting ISOs together, etc. This part is all normal practice AFAIK and it's not unusual if it takes a week longer or so than anticipated.
Linux compat is basically a set of RedHat rpms, and some layer over the BSD kernel that makes it able to talk with apps that expect a linux kernel. We had linux-6.1 and now we have 7.1. This refers to the RH version numbers.
On a releng_4_6 box:
# uname -a
FreeBSD gateway.home.ricin.net 4.6-RELEASE FreeBSD 4.6-RELEASE #0:
On another box at -stable:
workstation# uname -a
FreeBSD workstation.home.ricin.net 4.6-RC FreeBSD 4.6-RC #0
It's only logical that the sec. branch of 4.6 would start with the release "patchlevel 0" :)