FreeBSD for Linux Users

Printable View

September 8th, 2009, 06:40 AM
gore

FreeBSD for Linux Users

This is a thread for people who use Linux and are trying to use FreeBSD but can't seem to figure out why some things aren't working the same as they do in Linux.

FreeBSD and Linux are both similar, but that doesn't mean they're exactly the same. Linux is a clone of SunOS written by Linus Torvalds, because as he put it "I wanted a similar environment to the one I had at the University, and I couldn't find anything suitable, but doing computers all my life, I decided I'd write my own".

Sun OS is basically BSD with some other stuff added in but Linux today is a lot more user friendly than Unix was or is now. Most people running Unix on a big server, are NOT running some shiny KDE desktop with 3D FX. They're probably not even running X. And if they are, it's probably either CDE, TWM, or maybe FVWM.

So anyway, there are differences, and what appears to be no good reason as to why something in Linux doesn't work. Well, there is a good reason it's not working; it's not Linux!

--------------------

Linux:

Code:

ls --color # Display results of "ls" in color.

FreeBSD:

Code:

ls -G #Display the results of "ls" in color on FreeBSD.

------

Linux -

Code:

updatedb

# Update the Database for the "locate" command.

FreeBSD -

Code:

/usr/libexec/locate.updatedb

# Update the Database for "locate" in FreeBSD

In FreeBSD, Ethernet cards have names that match the device model, like this:
“/dev/re0″

Instead of :

“/dev/eth0″

Your HD is more likely “/dev/ad10s1″ than “/dev/sda1″

The defualt boot isn't going to load any GUI either in FreeBSD, you'll have to do that yourself, like this:

Type this; gdm_enable=”YES” inside /etc/rc.conf.

You will need to edit ~/.xinitrc and add “gnome-session”

In Linux, Sound probably already works out of the box. In FreeBSD, no...

You'll have to do something to get sound going. Like for example, this as root:

Code:

kldload snd_driver

This takes a minute, and then if you want to add it without typing this all the time:

Code:

cat /dev/sndstat

Look for the driver name RIGHT after “kld” in that line. You're going to add it here:

Put RIGHTAFTERKLD_load=”YES” to /boot/loader.conf

What about this update thing? In Linux you have a bunch of utilities to do this, and sometimes don't even need to do anything at all... Well, in FreeBSD the easiest way, if you don't have custom Kernels, is this:

freebsd-update (Which will show a list of command line arguments to run with it) like for example:

Code:

freebsd-update fetch

And then:

Code:

freebsd-update install

You can also use portsnap.

Anyone who wants to add to this, feel free to do so.
September 8th, 2009, 02:11 PM
rotoR*46

Hey gore nice to see you starting thread on BSD.
Well all I want to know is how to install X in BSD and what all the fundamental differences between the SunOS and BSD..?:confused:
BTW what are these TWM, FVWM.
September 8th, 2009, 10:56 PM
gore

Quote:

Originally Posted by rotoR*46

Hey gore nice to see you starting thread on BSD.

I've actually got a sticky thread in here for BSD, and I think it's under the Linux one I did a long time ago. Since I use both Linux and BSD, I made a thread for both going over differences. I'll multi-quote your reply so I can answer it in a way that won't look like spaghetti ;)

Quote:

Well all I want to know is how to install X in BSD

You don't have to install it unless you told the installer not too. Basically, FreeBSD has an installation process not unlike Slackware Linux. If you've ever installed that you know what I mean; The install screen itself is a similar color, and it's actually easy once you get the hang of it. I wrote an installation tutorial for not only installing FreeBSD, but I actually wrote another one for dual booting FreeBSD and Slackware Linux together and I went step by step on which button to press and even when, and basically did a hand holding installation tutorial that would tell you to install one of them, and how, and then, to install the other, and how, and what to do after to get them dual booting. If you look through the tutorials, you'll find them.

Anyway, for X to work on FreeBSD, a lot of people for some reason always mess with things they don't need to touch assuming that FreeBSD is hard, and that they have to follow an installer from the FreeBSD handbook online line for line, which you don't.

I've not only installed FreeBSD a hundred times, I still haven't read through how to do it, so I'm not even sure what the documentation says to do, I haven't read it since FreeBSD 4.0 was released. The same for Slackware; I've written a tutorial on how to install it but haven't actually read how to do it so I'm not even sure what the docs for that say as I haven't read them. I just figured it out myself. Once I had a working system, I wrote the installer tutorial.

Basically, do this:

1. Get FreeBSD on CD or a DVD.
2. Install FreeBSD, and, when it comes to the ports, just have it install everything. This way you know you've got what you need. If this fails for some reason, install the base system, and do this:
pkg_add -r kde gnome fvwm2
Hit Enter. Since the pkg_add tool can take multiple arguments, you can install gnome, KDE, and others all at once, and it will download them all for you, compile, install, and set it up with a basic configuration you can change if you like.

Then, do this:
pkg_add -r gdm kdm

I recommend kdm, but gdm is fine too. Just remember that gdm doesn't always show you every window manager you have installed. It won't. KDM however, will.

Once you're done, type this:

kdm

Then you'll see it load up, and show you a log in with a GUI. Select what Window Manager you want, and log in.

Quote:

and what all the fundamental differences between the SunOS and BSD..?:confused:

That depends; Early versions of Sun OS, WERE BSD. Sun OS is made by Sun, which, was in part, founded by Bill Joy. Bill was one of the guys at Berkeley, who along with Marshall Kirk McKusick, and others, wrote BSD. Bill then went on to get into Sun, and used BSD on Workstations. They basically took BSD, and sold it on commodity hardware. So really the only difference is that Sun OS is now called Solaris, and Solaris was changed from BSD by having things added to it. It's sort of like how BSD/OS was difference from BSD, and BSD/OS and FreeBSD and NetBSD are different. They all are a little different, but when it comes down to it, they have a lot in common.

Quote:

BTW what are these TWM, FVWM.

Those are Window Managers. VERY basic ones. TWM is basically a VERY low requirement Window Manager with no idea of a desktop, or special FX. It's a basic desktop that used to be standard with X WAY back in the day.

FVWM is another Window Manager that is basically very dated looking by todays standards. Both of them require VERY little RAM to use, but offer you a GUI on Unix. FVWM looks a lot like CDE actually.

You can see what it looks like here:

http://en.wikipedia.org/wiki/Twm

http://en.wikipedia.org/wiki/FVWM

FVWM can look a lot different than that though; there is a version called FVWM 95, which looks like the Windows 95 GUI. I've used all three, and they work for what they were made for, but most people would probably use others.

Oh, there is also a version of FVWM called.... I think crystal or something... It's a lot more "pretty" than the others, but I think you can find a link to what it looks like in the Wiki article on FVWM I showed you.

http://en.wikipedia.org/wiki/FVWM-Crystal

There it is.
September 9th, 2009, 03:04 PM
rotoR*46

Quote:

Originally Posted by gore

I've actually got a sticky thread in here for BSD, and I think it's under the Linux one I did a long time ago. Since I use both Linux and BSD, I made a thread for both going over differences. I'll multi-quote your reply so I can answer it in a way that won't look like spaghetti ;)

You don't have to install it unless you told the installer not too. Basically, FreeBSD has an installation process not unlike Slackware Linux. If you've ever installed that you know what I mean; The install screen itself is a similar color, and it's actually easy once you get the hang of it. I wrote an installation tutorial for not only installing FreeBSD, but I actually wrote another one for dual booting FreeBSD and Slackware Linux together and I went step by step on which button to press and even when, and basically did a hand holding installation tutorial that would tell you to install one of them, and how, and then, to install the other, and how, and what to do after to get them dual booting. If you look through the tutorials, you'll find them.

Anyway, for X to work on FreeBSD, a lot of people for some reason always mess with things they don't need to touch assuming that FreeBSD is hard, and that they have to follow an installer from the FreeBSD handbook online line for line, which you don't.

I've not only installed FreeBSD a hundred times, I still haven't read through how to do it, so I'm not even sure what the documentation says to do, I haven't read it since FreeBSD 4.0 was released. The same for Slackware; I've written a tutorial on how to install it but haven't actually read how to do it so I'm not even sure what the docs for that say as I haven't read them. I just figured it out myself. Once I had a working system, I wrote the installer tutorial.

Basically, do this:

1. Get FreeBSD on CD or a DVD.
2. Install FreeBSD, and, when it comes to the ports, just have it install everything. This way you know you've got what you need. If this fails for some reason, install the base system, and do this:
pkg_add -r kde gnome fvwm2
Hit Enter. Since the pkg_add tool can take multiple arguments, you can install gnome, KDE, and others all at once, and it will download them all for you, compile, install, and set it up with a basic configuration you can change if you like.

Then, do this:
pkg_add -r gdm kdm

I recommend kdm, but gdm is fine too. Just remember that gdm doesn't always show you every window manager you have installed. It won't. KDM however, will.

Once you're done, type this:

kdm

Then you'll see it load up, and show you a log in with a GUI. Select what Window Manager you want, and log in.

That depends; Early versions of Sun OS, WERE BSD. Sun OS is made by Sun, which, was in part, founded by Bill Joy. Bill was one of the guys at Berkeley, who along with Marshall Kirk McKusick, and others, wrote BSD. Bill then went on to get into Sun, and used BSD on Workstations. They basically took BSD, and sold it on commodity hardware. So really the only difference is that Sun OS is now called Solaris, and Solaris was changed from BSD by having things added to it. It's sort of like how BSD/OS was difference from BSD, and BSD/OS and FreeBSD and NetBSD are different. They all are a little different, but when it comes down to it, they have a lot in common.

Those are Window Managers. VERY basic ones. TWM is basically a VERY low requirement Window Manager with no idea of a desktop, or special FX. It's a basic desktop that used to be standard with X WAY back in the day.

FVWM is another Window Manager that is basically very dated looking by todays standards. Both of them require VERY little RAM to use, but offer you a GUI on Unix. FVWM looks a lot like CDE actually.

You can see what it looks like here:

http://en.wikipedia.org/wiki/Twm

http://en.wikipedia.org/wiki/FVWM

FVWM can look a lot different than that though; there is a version called FVWM 95, which looks like the Windows 95 GUI. I've used all three, and they work for what they were made for, but most people would probably use others.

Oh, there is also a version of FVWM called.... I think crystal or something... It's a lot more "pretty" than the others, but I think you can find a link to what it looks like in the Wiki article on FVWM I showed you.

http://en.wikipedia.org/wiki/FVWM-Crystal

There it is.

Thanks alot DrGore..
infact I used your tut on BSD installation and its a wonderful piece of cake.
im still on the intermediate stair.. im pushing to be an artist in its own terms:)

thanks again!:D
September 9th, 2009, 07:01 PM
gore

You're welcome.
September 10th, 2009, 11:51 PM
gore

Keeping FreeBSD up to date -

http://www.taosecurity.com/keeping_f...p-to-date.html

http://www.taosecurity.com/keeping_f...p-to-date.html

/* Side note; You don't have to be running the 5.x version the author is running to use this guide*/

Introduction

An important system administration task, and a principle of running a defensible network, is keeping operating systems and applications up-to-date. Running current software is critical when older services are vulnerable to exploitation. Obtaining new features not found in older applications is another reason to run current software. Fortunately, open source software offers a variety of means to give users a secure, capable computing environment.

This article presents multiple ways to keep the FreeBSD operating system up-to-date. I take a FreeBSD 5.2.1 RELEASE system through a subset of security advisories to explain the different sorts of patches an administrator might apply. I describe how to use the FreeBSD ports tree and related tools to keep non-OS applications up-to-date in the following article:

http://www.taosecurity.com/keeping_f...p-to-date.html

I chose FreeBSD 5.2.1, released in February 2004, as my reference platform because it offers a security history suitable for describing multiple upgrade cases. At the time of writing FreeBSD 5.3 RELEASE is about a month old, and only two security advisories have been published thus far. Readers wondering why someone might want to install an "old" OS version can imagine that there might be an application supported only on FreeBSD 5.2.1 and not yet officially ready for 5.3, prompting an administrator to run a 5.2.1 box.

All of the work done in this article was done remotely via OpenSSH. One danger of performing remote upgrades is losing connection during a critical phase of the process. One software-based way to deal with this issue is to conduct all remote upgrades within a screen(1) session. [1] Should you lose connectivity during the upgrade while running screen, your session will continue uninterrupted. The screen(1) program has suffered security problems in the past, so balance its features against the possible risks.

My advice on administering this reference platform is based on deploying FreeBSD on servers, workstations, and laptops since 2000. The article represents a mix of my interpretations of official FreeBSD documentation, inputs from mentors, and the result of my own experimentation and deployment strategies. This guide cannot be anywhere near a complete reference on keeping FreeBSD up-to-date or maintaining a secure system. I strongly recommend reading the excellent FreeBSD Handbook as well as the multiple helpful published books on FreeBSD.

If you are reading this as a hard copy, the right hand side of the page may be c ut off. This is important when long URLs or command line statements are involve d. Please refer to the HTML version of this document for the authoritative vers ion.

FreeBSD Versions

Before explaining ways to keep the FreeBSD OS up-to-date, I must briefly expand on the idea of the term "up-to-date." Thanks to FreeBSD's open source development methodology, any version of FreeBSD is available via check out from the Concurrent Versions System (CVS). [2] These versions can be represented by CVS revision tags. [3] The following examples begin with 5.3 RELEASE, the most recently published version of FreeBSD:

* RELENG_5_3_0_RELEASE is FreeBSD 5.3 RELEASE, just as you might get on CD.
* RELENG_5_3 is the "security" branch for 5.3, which is FreeBSD 5.3 RELEASE with patches for security advisories and critical fixes applied.
* RELENG_5 is the development line of the FreeBSD 5 tree, also known as 5-STABLE
* . ("dot"), also known as HEAD, is the development line of the next version of FreeBSD, 6.0, also known as 6-CURRENT or simply CURRENT.

Linux users should note that these CVS revision tags do not pertain to the FreeBSD kernel alone. FreeBSD is developed as an integrated system, with a kernel matching userland tools. One should not run a kernel compiled for FreeBSD 5.3 RELEASE on a CURRENT machine. The kernel and all userland utilities are meant to be upgraded simultaneously, and must be kept synchronized. While Linux users are usually forced to acknowledge this good system administration practice when they upgrade major versions of their kernel (e.g., 2.2 to 2.4, or 2.4 to 2.6), they often maintain the same userland across minor kernel versions. FreeBSD strongly encourages users to always keep the userland and kernel in sync using the methods explained in the Handbook and elaborated upon in this document.

When thinking of what it means to be "up-to-date," one can see that the "oldest" version of FreeBSD as of version 5.3 is that which was most recently "pressed to CD" -- RELENG_5_3_0_RELEASE or FreeBSD 5.3 RELEASE. The "newest" would be HEAD or CURRENT, a constantly moving target modified and improved on a daily basis. How does an administrator decide what to run on her machines?

I prefer to begin a system's life by installing RELEASE software, like FreeBSD 5.3 RELEASE. As long as the systems performs as I would expect it to, I then track the RELENG_5_3 or "security" branch. This allows me to incorporate critical bug and security fixes that could jeopardize the system.

Occasionally I may encounter a system that requires a feature (like supporting a new piece of hardware) not present in the RELEASE or security branches. In cases where that feature is supported by STABLE, I will upgrade to that branch. In the rare cases where not even STABLE has the feature I need, I might install a snapshot of the CURRENT branch. I do not recommend running CURRENT in production environments as it is not supported like the RELEASE or STABLE versions are.

Learning About Security Issues

FreeBSD security advisories are published at the FreeBSD security page and at the freebsd-security-notifications mailing list. [4,5] I recommend all FreeBSD users subscribe to the moderated, very low volume notification mailing list. The advisories provide background, a problem description, an impact statement, workaround advice, a solution to fix the problem, and correction details. We'll take a closer look at an actual security advisory when we learn how to apply patches manually to the operating system.

Starting with the Installation

Let's start with the most common deployment scenario, using FreeBSD 5.2.1 RELEASE as our reference platform. For this version, the CVS tag is RELENG_5_2_1_RELEASE for the version shipped on CD and RELENG_5_2 for the security branch. (RELENG_5_2 applies even to FreeBSD 5.2.1.)

The administrator installs FreeBSD 5.2.1 RELEASE from CD on a new server. She installs the Developer distribution set so she has "Full sources, binaries and doc but no games." When installation is done, a check of uname output shows what the system looks like prior to any changes:

Code:

freebsd521:/root# uname -a FreeBSD freebsd521.taosecurity.com 5.2.1-RELEASE FreeBSD 5.2.1-RELEASE #0: Mon Feb 23 20:45:55 GMT 2004 root@wv1u.btc.adaptec.com:/usr/obj/usr/src/sys/GENERIC i386

She does not need to modify the kernel and is running the GENERIC version shipped with the OS. She does not need any enhancements offered by the STABLE tree and decides to track the 5.2 security branch.

Binary OS and Userland Updates with FreeBSD Update

Administrators who begin with a RELEASE system, who do not make any changes to the FreeBSD GENERIC kernel, and who have not made any changes to the userland, have a strong case for using binary upgrades. Binary upgrades replace the files copied from the original RELEASE CD-ROM (for example) with upgraded versions patched to address security issues.

Using Colin Percival's FreeBSD Update tool, our administrator can quickly bring the system fully up-to-date with respect to the 5.2 security branch. [6] Remember her system must meet be a stock RELEASE installation with no userland or kernel changes to take full advantage of FreeBSD Update's ability to address security concerns.

The administrator installs and runs FreeBSD Update by retrieving the tool as a remote, precompiled package. (Building the tool from source through the ports system as another acceptable option, and is actually preferred from a security standpoint.)

Code:

freebsd521:/root# pkg_add -vr freebsd-update looking up ftp.freebsd.org connecting to ftp.freebsd.org:21 setting passive mode opening data connection initiating transfer Fetching ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages- 5.2.1-release/Latest/freebsd-update.tbz...+CONTENTS ...edited... extract: Package name is freebsd-update-1.4 extract: CWD to /usr/local extract: /usr/local/man/man5/freebsd-update.conf.5.gz extract: /usr/local/man/man8/freebsd-update.8.gz extract: /usr/local/sbin/freebsd-update extract: /usr/local/sbin/freebsd-update-verify extract: /usr/local/etc/freebsd-update.conf.sample extract: /usr/local/share/doc/freebsd-update/LICENSE extract: /usr/local/share/doc/freebsd-update/README extract: /usr/local/share/doc/freebsd-update/VERSION extract: CWD to . Running mtree for freebsd-update-1.4.. mtree -U -f +MTREE_DIRS -d -e -p /usr/local >/dev/null Attempting to record package into /var/db/pkg/freebsd-update-1.4.. Trying to record dependency on package 'bsdiff-4.1' with 'misc/bsdiff' origin. Package freebsd-update-1.4 registered in /var/db/pkg/freebsd-update-1.4 Before you can use this, you will have to create an update configuration file specifying the server to fetch updates from and the trusted public key fingerprint. A sample configuration file has been installed in /usr/local/etc/freebsd-update.conf.sample which will fetch updates built by the author. If you trust the author to securely build binary updates for you to blindly install on this machine, copy that file to /usr/local/etc/freebsd-update.conf otherwise, create that file as appropriate. If you find FreeBSD Update useful, please consider sending a donation to the author: http://www.daemonology.net/freebsd-update/donating.html

Next she creates a needed directory and makes a copy of a default configuration file:

Code:

freebsd521:/root# mkdir -p /usr/local/freebsd-update freebsd521:/root# cp /usr/local/etc/freebsd-update.conf.sample /usr/local/etc/freebsd-update.conf

Finally she is ready to retrieve and apply updates. Remember to run 'rehash' if you need to recompute the hash table for $PATH used by the /bin/csh shell:

Code:

freebsd521:/root# freebsd-update fetch Fetching public key... Fetching updates signature... Fetching updates... Fetching hash list signature... Fetching hash list... Examining local system... Fetching updates... /boot/kernel/kernel... /boot/kernel/linux.ko... /lib/libcrypto.so.3... /usr/bin/cvs... /usr/bin/fetch... /usr/include/krb5-protos.h... /usr/include/netinet/ip6.h... /usr/include/netinet/tcp_var.h... /usr/include/openssl/opensslv.h... /usr/lib/libcrypto.a... /usr/lib/libcrypto_p.a... /usr/lib/libkrb5.a... /usr/lib/libkrb5.so.7... /usr/lib/libkrb5_p.a... /usr/lib/libssl.a... /usr/lib/libssl.so.3... /usr/lib/libssl_p.a... /usr/libexec/kdc... /usr/share/man/man8/kdc.8.gz... Updates fetched To install these updates, run: '/usr/local/sbin/freebsd-update install' Don't forget to rebuild any statically linked ports to use the updated libraries after you install them.

We see this process has downloaded a variety of files, including a new kernel (named "kernel"), a new kernel module (linux.ko), and a variety of binaries, libraries, and man pages.

Next the administrator applies the patches:

Code:

freebsd521:/root# freebsd-update install Backing up /boot/kernel/kernel... Installing new /boot/kernel/kernel... Backing up /boot/kernel/linux.ko... Installing new /boot/kernel/linux.ko... Backing up /lib/libcrypto.so.3... Installing new /lib/libcrypto.so.3... Backing up /usr/bin/cvs... Installing new /usr/bin/cvs... ...edited... Backing up /usr/share/man/man8/kdc.8.gz... Installing new /usr/share/man/man8/kdc.8.gz...

When done, the administrator reboots the system. A reboot is needed because the kernel itself was updated. After reboot, observe the new uname output:

Code:

freebsd521:/root# uname -a FreeBSD freebsd521.taosecurity.com 5.2.1-SECURITY FreeBSD 5.2.1-SECURITY #0: Tue Sep 28 17:27:41 GMT 2004 root@builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC i386

Whereas the last uname output showed "5.2.1-RELEASE" as the version, with a kernel compilation date of "Mon Feb 23 20:45:55 GMT 2004", the security branch shows "5.2.1-SECURITY" and "Tue Sep 28 17:27:41 GMT 2004". You can verify that your FreeBSD system required no other binary upgrades by running FreeBSD Update again:

Code:

freebsd521:/root# freebsd-update fetch Fetching updates signature... Fetching hash list signature... Examining local system... No updates available

Since no updates are available, the system is patched.

FreeBSD Update is a simple yet powerful way to keep a FreeBSD machine aligned with the security branch. Its primary drawback is its inability to update a kernel customized by the system administrator. Since it's not possible for Colin to imagine all of the different kernel modifications administrators might make, he is restricted to building binary upgrades of the stock GENERIC kernel. While the GENERIC kernel is appropriate for many deployments, its lack of IPSec support, for example, might prompt an administrator to deviate from the GENERIC path.

FreeBSD Update cannot handle changes to the userland that deviate from what was packaged with a RELEASE, either. If an administrator tinkers with a driver or tool, and that file subsequently requires a security fix, FreeBSD Update will not try to replace it be default.

However, FreeBSD Update's author Colin Percival notes:

"FreeBSD Update can be forced to download security fixes for files which have been locally modified by using the --branch option starting with version 1.5. The "branches" here are "nocrypto", "crypto", "krb4", and "krb5"; most users would be running a system with cryptography but without optional Kerberos support, so they would use "--branch crypto". Of course, this will obliterate any local changes they have made to the files being updated, but it's useful if you've recompiled the world without actually making any changes."
September 10th, 2009, 11:51 PM
gore

Applying Kernel Patches Manually

FreeBSD Update might seem too simple for your tastes. Alternatively, you want the control of working with the source yourself or you might be running a custom kernel. Whenever you change the userland or kernel beyond what was shipped with a RELEASE, binary upgrades become problematic.

This section demonstrates how to patch a FreeBSD 5.2.1 RELEASE system, showing commands and output. Administrators learn of security issues by reading advisories, so it is helpful to see what those bulletins contain.

We start down the road of manual patching by looking at the first security advisory to affect FreeBSD 5.2.1 RELEASE, of which an excerpt is printed below:

Code:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ============================================================================= FreeBSD-SA-04:04.tcp Security Advisory The FreeBSD Project Topic: many out-of-sequence TCP packets denial-of-service Category: core Module: kernel Announced: 2004-03-02 Revised: 2004-03-16 Credits: iDEFENSE, Alexander Cuttergo Affects: All FreeBSD releases Corrected: 2004-03-02 17:19:18 UTC (RELENG_4) 2004-03-16 13:47:33 UTC (RELENG_5_2, 5.2.1-RELEASE-p2) 2004-03-15 20:02:06 UTC (RELENG_5_1, 5.1-RELEASE-p15) 2004-03-02 17:26:33 UTC (RELENG_4_9, 4.9-RELEASE-p3) 2004-03-02 17:27:47 UTC (RELENG_4_8, 4.8-RELEASE-p16) 2004-03-17 10:50:45 UTC (RELENG_4_7, 4.7-RELEASE-p26) CVE Name: CAN-2004-0171 FreeBSD only: NO 0. Revision History v1.0 2004-03-02 Initial release. v1.1 2004-03-17 Fix minor performance issue in 5.2.1 patch. Corrections for RELENG_5_1 and RELENG_4_7 added. Note Alexander Cuttergo as the discoverer of this issue. I. Background The Transmission Control Protocol (TCP) of the TCP/IP protocol suite provides a connection-oriented, reliable, sequence-preserving data stream service. When network packets making up a TCP stream (``TCP segments'') are received out-of-sequence, they are maintained in a reassembly queue by the destination system until they can be re-ordered and re-assembled. II. Problem Description FreeBSD does not limit the number of TCP segments that may be held in a reassembly queue. III. Impact A remote attacker may conduct a low-bandwidth denial-of-service attack against a machine providing services based on TCP (there are many such services, including HTTP, SMTP, and FTP). By sending many out-of-sequence TCP segments, the attacker can cause the target machine to consume all available memory buffers (``mbufs''), likely leading to a system crash. IV. Workaround It may be possible to mitigate some denial-of-service attacks by implementing timeouts at the application level. V. Solution Do one of the following: 1) Upgrade your vulnerable system to 4-STABLE, or to the RELENG_5_2, RELENG_4_9, or RELENG_4_8 security branch dated after the correction date. OR 2) Patch your present system: The following patch has been verified to apply to FreeBSD 4.x and 5.x systems. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. [FreeBSD 5.2] # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-04:04/tcp52.patch # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-04:04/tcp52.patch.asc ...edited... b) Apply the patch. # cd /usr/src # patch < /path/to/patch c) Recompile your kernel as described in <URL:http://www.freebsd.org/handbook/kernelconfig.html> and reboot the system. VI. Correction details The following list contains the revision numbers of each file that was corrected in FreeBSD. Branch Revision Path - ------------------------------------------------------------------------- ...edited... RELENG_5_2 src/UPDATING 1.282.2.10 src/sys/conf/newvers.sh 1.56.2.9 src/sys/netinet/tcp_input.c 1.217.2.3 src/sys/netinet/tcp_subr.c 1.169.2.4 src/sys/netinet/tcp_var.h 1.93.2.2 ...edited... - ------------------------------------------------------------------------- VII. References <URL:http://www.idefense.com/application/poi/display?id=78&type=vulnerabilities> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAWC4yFdaIBMps37IRAgulAJ93O5yH4Z49oTx4HEdRJK+6sLco2gCfYCEZ NpPTCWlG1oyLjOL2y6zKBfs= =Naox -----END PGP SIGNATURE-----

Advisory FreeBSD-SA-04:04.tcp describes a potential denial of service condition in the FreeBSD kernel. The kernel handles reassembling TCP packets, so the kernel must be upgraded to fix this problem.

We see that the solution for this problem requires upgrading to the RELENG_5_2 branch dated after date of the files affected by the advisory, or applying a patch located at this link for FreeBSD 5.2:

ftp://ftp.FreeBSD.org/pub/FreeBSD/CE...04/tcp52.patch

Here we demonstrate how to apply a patch to the kernel, and then how to recompile the kernel. Where wget(1) is used, feel free to substitute fetch(1) if wget(1) is not installed on your system.

First we install GNU Privacy Guard (gpg) so we can verify the authenticity of the patch, then obtain and import the key of the FreeBSD security officer:

Code:

freebsd521:/root# pkg_add -vr gnupg ...edited... Package gnupg-1.2.3_4 registered in /var/db/pkg/gnupg-1.2.3_4 freebsd521:/root# rehash freebsd521:/root# gpg --version gpg (GnuPG) 1.2.3 Copyright (C) 2003 Free Software Foundation, Inc. This program comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the file COPYING for details. Home: ~/.gnupg Supported algorithms: Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA, ELG Cipher: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH Hash: MD5, SHA1, RIPEMD160, SHA256 Compression: Uncompressed, ZIP, ZLIB freebsd521:/root# wget ftp://ftp.freebsd.org/pub/FreeBSD/CERT/public_key.asc ...edited... freebsd521:/root# gpg --import public_key.asc gpg: /root/.gnupg: directory created gpg: new configuration file `/root/.gnupg/gpg.conf' created gpg: WARNING: options in `/root/.gnupg/gpg.conf' are not yet active during this run gpg: keyring `/root/.gnupg/secring.gpg' created gpg: keyring `/root/.gnupg/pubring.gpg' created gpg: /root/.gnupg/trustdb.gpg: trustdb created gpg: key CA6CDFB2: public key "FreeBSD Security Officer <security-officer@FreeBSD.org>" imported gpg: Total number processed: 1 gpg: imported: 1

Alternatively, you can import the keys of all of the developers right from your hard drive:

Code:

gpg --import /usr/share/doc/en_US.ISO8859-1/books/handbook/pgpkeys-developers.html

Second we download the patch and the GPG-signature, and then verify the signature:

Code:

freebsd521:/root# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-04:04/tcp52.patch Receiving tcp52.patch (6182 bytes): 100% 6182 bytes transferred in 0.1 seconds (49.28 kBps) freebsd521:/root# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-04:04/tcp52.patch.asc Receiving tcp52.patch.asc (186 bytes): 100% 186 bytes transferred in 0.0 seconds (23.98 kBps) freebsd521:/root# gpg --verify tcp52.patch.asc tcp52.patch gpg: Signature made Tue Mar 2 12:10:17 2004 EST using DSA key ID CA6CDFB2 gpg: Good signature from "FreeBSD Security Officer <security-officer@FreeBSD.org>" gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: C374 0FC5 69A6 FBB1 4AED B131 15D6 8804 CA6C DFB2

GPG warns us that we have not taken any steps to trust the signature of the FreeBSD Security Officer. One of the ways to make this warning disappear would be to sign the key of the FreeBSD Security Officer ourselves. We might do that after confirming in person or on the telephone that the primary key fingerprint of the FreeBSD Security Officer's key is as stated in the output above. (Beyond this example, I will not show verifying future patches.)

For now we assume that the tcp52.patch has not been tampered with and move on to applying it per the advisory's instructions:

Code:

freebsd521:/usr/src# patch < /root/tcp52.patch Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |? tcp_reass-5.2.1-20040301.patch |Index: tcp_input.c |=================================================================== |RCS file: /home/ncvs/src/sys/netinet/tcp_input.c,v |retrieving revision 1.217.2.1 |diff -u -p -r1.217.2.1 tcp_input.c |--- sys/netinet/tcp_input.c 9 Jan 2004 12:32:36 -0000 1.217.2.1 |+++ sys/netinet/tcp_input.c 1 Mar 2004 15:18:54 -0000 -------------------------- Patching file sys/netinet/tcp_input.c using Plan A... Hunk #1 succeeded at 57. Hunk #2 succeeded at 99. Hunk #3 succeeded at 134. Hunk #4 succeeded at 192. Hunk #5 succeeded at 215. Hunk #6 succeeded at 226. Hunk #7 succeeded at 276. Hunk #8 succeeded at 312. Hunk #9 succeeded at 347. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: tcp_subr.c |=================================================================== |RCS file: /home/ncvs/src/sys/netinet/tcp_subr.c,v |retrieving revision 1.169.2.3 |diff -u -p -r1.169.2.3 tcp_subr.c |--- sys/netinet/tcp_subr.c 23 Feb 2004 15:32:55 -0000 1.169.2.3 |+++ sys/netinet/tcp_subr.c 1 Mar 2004 15:18:54 -0000 -------------------------- Patching file sys/netinet/tcp_subr.c using Plan A... Hunk #1 succeeded at 286. Hunk #2 succeeded at 709. Hunk #3 succeeded at 771. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: tcp_var.h |================================================================ |RCS file: /home/ncvs/src/sys/netinet/tcp_var.h,v |retrieving revision 1.93.2.1 |diff -u -p -r1.93.2.1 tcp_var.h |--- sys/netinet/tcp_var.h 9 Jan 2004 12:32:36 -0000 1.93.2.1 |+++ sys/netinet/tcp_var.h 1 Mar 2004 15:18:55 -0000 -------------------------- Patching file sys/netinet/tcp_var.h using Plan A... Hunk #1 succeeded at 54. Hunk #2 succeeded at 513. done

Now that the patch is applied, we must rebuild our kernel. [8] Since we are going to be recompiling the kernel, we are free to make changes to its configuration. We copy the GENERIC kernel to a file named for our system (freebsd521). Readers familiar with FreeBSD conventions might recognize that kernel configuration files are normally named in uppercase, e.g., FREEBSD521. This difference does not affect the outcome, but readers are encouraged to name their kernel configuration file according to the uppercase convention:

Code:

freebsd521:/usr/src# cd /usr/src/sys/i386/conf

Code:

freebsd521:/usr/src/sys/i386/conf# cp GENERIC freebsd521

Next we make a few changes to omit support for the Intel 486 and 586 class CPUs and change the kernel identifier to our hostname:

Code:

# $FreeBSD: src/sys/i386/conf/GENERIC,v 1.394.2.3 2004/01/26 19:42:11 nectar Exp $ machine i386 #cpu I486_CPU #cpu I586_CPU cpu I686_CPU #ident GENERIC ident freebsd521

There are dozens of other changes that could be made, such as removing support for unnecessary hardware, or making optimizations. I recommend reviewing the Handbook or one of the excellent books on FreeBSD to learn more about kernel modifications.

Finally we compile and install the new kernel:

Code:

freebsd521:/usr/src# make buildkernel KERNCONF=freebsd521 -------------------------------------------------------------- >>> Kernel build for freebsd521 started on Sat Nov 27 19:45:44 EST 2004 -------------------------------------------------------------- ===> freebsd521 mkdir -p /usr/obj/usr/src/sys cd /usr/src/sys/i386/conf; PATH=/usr/obj/usr/src/i386/legacy/usr/sbin: /usr/obj/usr/src/i386/legacy/usr/bin:/usr/obj/usr/src/i386/legacy/usr/games: /usr/obj/usr/src/i386/usr/sbin:/usr/obj/usr/src/i386/usr/bin:/usr/obj/usr /src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin config -d /usr/obj/usr/src/sys/freebsd521 /usr/src/sys/i386/conf/freebsd521 Kernel build directory is /usr/obj/usr/src/sys/freebsd521 ...edited... -------------------------------------------------------------- >>> Kernel build for freebsd521 completed on Sat Nov 27 21:25:30 EST 2004 -------------------------------------------------------------- freebsd521:/usr/src# make installkernel KERNCONF=freebsd521 cd /usr/obj/usr/src/sys/freebsd521; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=i386 MACHINE=i386 CPUTYPE= GROFF_BIN_PATH=/usr/obj/usr /src/i386/legacy/usr/bin GROFF_FONT_PATH=/usr/obj/usr/src/i386/legacy /usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/usr/src/i386/legacy /usr/share/tmac PATH=/usr/obj/usr/src/i386/legacy/usr/sbin: /usr/obj/usr/src/i386/legacy/usr/bin:/usr/obj/usr/src/i386/legacy /usr/games:/usr/obj/usr/src/i386/usr/sbin:/usr/obj/usr/src/i386/usr /bin:/usr/obj/usr/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin make KERNEL=kernel install ...edited... ===> vesa install -o root -g wheel -m 555 vesa.ko /boot/kernel kldxref /boot/kernel freebsd521:/usr/src# shutdown -r now

After the reboot, the uname output is slightly different:

Code:

freebsd521:/root# uname -a FreeBSD freebsd521.taosecurity.com 5.2.1-RELEASE FreeBSD 5.2.1-RELEASE #0: Sat Nov 27 20:36:48 EST 2004 root@freebsd521.taosecurity.com:/usr/obj/usr/src/sys/freebsd521 i386

Whereas the original system's uname output showed the GENERIC kernel, this system displays a kernel called freebsd521.

This example demonstrated how to patch and recompile the FreeBSD kernel. The main drawback for this sort of patching is the time required to recompile and install the kernel, as it can take a long time on older machines. It is possible to recompile the world and kernel on a fast machine, and then install both on a slower machine. I wrote a Blog entry demonstrating how to do this, titled "Building Kernel and World on One System, Installing on Another."
September 12th, 2009, 11:18 PM
SirDice

Quote:

That depends; Early versions of Sun OS, WERE BSD. Sun OS is made by Sun, which, was in part, founded by Bill Joy. Bill was one of the guys at Berkeley, who along with Marshall Kirk McKusick, and others, wrote BSD. Bill then went on to get into Sun, and used BSD on Workstations. They basically took BSD, and sold it on commodity hardware. So really the only difference is that Sun OS is now called Solaris, and Solaris was changed from BSD by having things added to it. It's sort of like how BSD/OS was difference from BSD, and BSD/OS and FreeBSD and NetBSD are different. They all are a little different, but when it comes down to it, they have a lot in common.

SunOS changed from being BSD based to System V Release 4 based with SunOS 5 aka Solaris 2. After SunOS 5.6 aka Solaris 2.6 Sun dropped the 2. in the Solaris name. So Solaris 7 is actually SunOS 5.7 and Solaris 10 is SunOS 5.10. The Solaris name is used almost exclusively to mean the SVR4 derived SunOS versions.
September 16th, 2009, 03:03 AM
gore

Quote:

Originally Posted by SirDice

SunOS changed from being BSD based to System V Release 4 based with SunOS 5 aka Solaris 2. After SunOS 5.6 aka Solaris 2.6 Sun dropped the 2. in the Solaris name. So Solaris 7 is actually SunOS 5.7 and Solaris 10 is SunOS 5.10. The Solaris name is used almost exclusively to mean the SVR4 derived SunOS versions.

Yea, I know, I wanted to make the point mostly that in the early days (When Bill Joy went there and wanted MKirkM to join him) that they had the idea of taking hardware and making their own machines, and selling it with BSD on it, and as Joy said "Make a lot of money because the others are using AT&T's Unix and Berkeley is better) and, he was right of course... AT&T laid the Unix Egg, but Berkeley sat on it and made it hatch... In the "Sun" lololololol. Come on that's golden lol.

But anyway, I found it weird that once Solaris became the "new version" they switched away more from the BSD area.

I've always wondered why they'd do that. BSD is so much better than SVR4 it's not even funny. The only thing SVR4 ever had going for it as usable, was Irix. I HIGHLY respect SGI.

By the way, why aren't you adding any tips in here? I know you are a BSD user, do you have any tips you could give to make this thread a little better? Anything can work for this, I more or less started it as a way for people who were used to Linux, to get used to BSD snice a couple of thnigs are much different, and eventually I'd like to make it sticky with a bunch of BSD info in it for anyone who wants to try BSD or get what the community here thinks of BSD.

If anyone else has any confusion about BSD, all you need to know really, is that BSD is more like Unix, and is based on the same code as Unix and by many, is REAL Unix, where Linux, is a clone of SunOS (Taken from Torvald's mouth about the inspiration for Linux being SunOS) and though BSD can't be called Unix legally, only lawyers seem to know the difference between BSD and Unix.

FreeBSD is one of th better BSDs you can get, and it's not only stable, but will work great on some old PC you have as a door stop. OpenBSD and NetBSD all are BSD too, but FreeBSD is probably the better of the three. For more info on why, you can check the Difference / Which version of BSD to use" thread.
October 7th, 2009, 11:49 AM
gore

I just found these and figured I'd put them here too since, well, one of them, is basically right on topic, and the rest can be of some help too:

FreeBSD for Linux users:

http://people.freebsd.org/~nik/Leeds

=================

I haven't looked at this yet, but it says the document is dated and I might have to update it one day and see if they like it.

http://people.freebsd.org/~murray/OS.pdf
=============================

http://people.freebsd.org/~murray/pr...29-msu-freebsd
==================================

Creating a Software Testing Environment Using FreeBSD

http://www.freebsd.org/doc/en_US.ISO...x/article.html
====================================

http://www.freebsd.org/doc/en_US.ISO...d/article.html
======================
http://www.freebsd.org/doc/en_US.ISO...n/article.html

This last one here is about Linux and FreeBSD.

The bottom line really is that basically, if you use Linux, you can probably use FreeBSD. It's no harder or easier in most cases than the other, though FreeBSD seems to stick with what it does a little more, where Linux installations for example, for VERY different, and upgrading is too.

FreeBSD VS Linux is more philosophical than technical probably 89% of the time. The rest of the time there is a difference in what you're doing, but a HUGE portion is basically the same and you'd have trouble finding someone who complained about using either.

============

For stability, I've personally been doing some of my OWN tests. I don't read little brochures and think "They wouldn't lie" lol. Over the past 5 years I've been doing my own stability / reliability test on FreeBSD VS Linux to see what was really true in those little statements.

Basically, I started slow, I set up a desktop machine with two partitions:

One had Slackware Linux on it, and the other was a FreeBSD installation. This is great because it's the EXACT hardware for the testing, no "Well what if the hardware was different" or "Well this and that" crap, the hardware and machine were exact!

I felt this was a better way to test because then I could say "Well, It was the same machine I was testing on so results are pure"...

Anyway, at first, the only differences you notice are that the font and size of text on screen look different. Literally that was it.

Slackware starts up without X running and so does FreeBSD. So literally the text size and font were the only things different.

After logging in, and checking speed, FreeBSD and Slackware both are quick OSs. Windows 2000 Professional was on this machine too, and anyone who says Windows can do whatever BSD and Linux can do, say that because they're on crack. The machine was an OLD box I had, and BSD and Slackware were usable on it. Windows... Let's just say I could re-compile a Kernel in almost the same time I waited for Windows to load one ;)

I eventually set up servers; SSH, FTP, Telnet, HTTP, SMTP, POP3...They performed almost the same. The main differences are that FreeBSD is slightly faster sometimes, and stability for both is VERY high. I still haven't came to a conclusion on which is more stable. After more than a year of non stop running, neither one is slowing down.