As bad as Netscape is, it's maintained a lot better for Linux than it is for other UNIX platforms (at least on i386).
You also seem to misunderstand the idea of Linux binary compatability -- it's not "emulation", the binaries run *natively*. The BSD kernel reconfigures itself to appear like a Linux kernel to the Linux binaries, and everything runs just as if it was on a Linux machine, on the bare hardware. Therefore Linux binaries run at full-speed, just like native BSD binaries. It's very cool - in fact, I'm typing this as we speak in a Linux mozilla daily build on my FreeBSD box.
There's a good entry in the FreeBSD handbook about this if you're interested in more details.
This has been relevant in the past, but it's basically a non-issue at the present time. For example, FreeBSD has blanket export permission for all things crypto thesedays.
One of the goals of the TrustedBSD project is to add POSIX capabilities to FreeBSD. A useful capability is CAP_NET_BIND_SERVICE, which allows daemons to be bound to low (1024) ports.
So don't worry, FreeBSD will soon give everyone in the world (not just Christians) the power to bind the daemons on their system.
Stay tuned. FreeBSD 5.0-CURRENT has working sftp support (as does OpenBSD, where the code came from). It will likely be backported to 4.1.1-STABLE in a week or two.
Well, as much as I hate to say something which might dispel your impression that BSD developers are amazing:-) this was actually very simple to achieve and involved REMOVING code which was keeping RSA *out* of the US version.
International folks have had real RSA since 4.0-RELEASE (and this was enabled by default on the releases by some third party CD distributors) - but as of 4.1.1 the main BSDi release of FreeBSD will have it enabled for all users.
The native OpenSSL RSA code was added back to OpenSSL (international people have already been using this since the beginning), meaning OpenSSH can now speak SSHv1 out of the box where before you had to install the rsaref library separately, and not everyone was allowed to use it.
The biggest upshot is that a default FreeBSD installation will come up running OpenSSH and speaking both SSH1 and SSH2 protocols when you reboot it after completeing the initial installation.
No-one's trying to claim this is some kind of breakthrough. IPv6 has been available on *BSD platforms for 3-4 years too, and for example the standard FreeBSD 4.0 from earlier this year was fully IPv6-enabled (and the more recent 4.1 even more so:-).
Nope, thats not what I was talking about. It is *a* problem with sprintf(), but it can be protected against without using snprintf(). Missing format strings are different.
Actually, what I meant was in reference to theformat string vulnerability: sprintf(buf, argv[1]) instead of sprintf(buf, "%s", argv[1]) kind of thing. Contrary to popular belief, sprintf() can be used safely as long as you check the length of your string before using it. It's often easiest to just use snprintf(), which makes for easier auditing and so on, but sprintf() isn't always wrong.
Yes, both FreeBSD and OpenBSD did a pro-active sweep several months ago to identify and fix any of these problems. We didn't find any security problems, but there were a few non-exploitable bugs in unprivileged apps which were caught (fixed prior to 4.1-RELEASE).
Of course, if you run third party software which we haven't yet audited then you might be vulnerable, but thats always the risk you take. FreeBSD is slowly working through the ports collection to try and audit this code.
With almost 3800 ports it's a large task, but it's bearing a lot of fruit - in fact we're discovering security problems in third party code at a faster rate than I have time to keep up with and write ports advisories for. Ultimately everyone who uses UNIX software will benefit from this work.
The BSD-derived FTP server had a problem of this class which was discovered and fixed a few months ago. However FreeBSD fixed it in our version back in 1996, so we were exempt from the ensuing security brouhaha:-)
It was something which was never an issue to begin with, because the code was written correctly from the start. "Format string vulnerabilities" result from improper use of functions like syslog() and sprintf(), and for whatever reason our code just didnt have any serious problems there.
Both FreeBSD and OpenBSD did a full audit sweep of our respective source trees soon after the class of "format string vulnerabilities" were discovered.
We didn't find anything serious, although there were a few in non-setuid binaries which of course aren't a security problem unless you use them in a weird way (like hooking them up to unfiltered network input or something). OpenBSD had a hole in setproctitle() in their ftpd a few months back, IIRC. Most of the changes we made were for "correctness" rather than a demonstrable security benefit.
By contrast, most Linux distros apparently have these problems (rpc.statd was one, as well as the ftpd problem which just about everyone (except FreeBSD;-) suffered, and apparently there are lots of other setuid binaries on Linux vulnerable to this local exploit). Make of this what you will:-)
The TCP part of TCP/IP works pretty well, the
problems are with the IP(v4) part which is running out of address space etc. Those are the issues IPv6 addresses.
Like it or not, TCP and UDP are goign to be
around for a very long time, so the layer 3 protocol they run over damn well better support them.
3.5 is the final scheduled release on the 3.X branch. The FreeBSD development model has multiple simultaneous branches, on which releases are periodically made as "snapshots" of the branch at that point in time.
Development on the branches never really stops, although it does slow down considerably once the branch reaches end-of-life (as 3.X is about to do). Heck, there are still even occasional commits to 2.2.8-STABLE and even 2.1.7.1-STABLE:-)
> FBSD is still probably vulrable to a procfs > exploit (although it hasn't been written yet)
Hrumph - there's nothing like jumping to conclusions. Do you really think FreeBSD coders are idiots and don't know how to fix bugs when they see them?
IIRC, OpenBSD was just as vulnerable to the problem as FreeBSD if you enabled procfs, the only difference being they didn't enable it in the default kernel.
Actually, OpenBSD *does* ship lynx in the base system (what's more, it was vulnerable to some of the recent security holes), as well as other stuff like apache.
As of 4.0-RELEASE (which came out in March), FreeBSD ships OpenSSH and OpenSSL in the base system (even on CD). This was shortly after the first OpenBSD release which also included OpenSSH, IIRC. NetBSD also ships OpenSSL (and they pre-dated FreeBSD in this regard, I believe).
Finally, as one of the FreeBSD Security Officers I'm not sure what you're talking about WRT "the ammount of exploits for the -current release" - if these really do exist (and I'd be surprised) then we certainly haven't been informed of them.
What there *has* been lately is a lot of FUD on Bugtraq about "FreeBSD is probably vulnerable to this, but I didn't check" and so forth, but not a lot of content (well, there were a couple of vulnerabilities which applied to the other BSDs as well). If you have anything solid to point to here I'd appreciate it if you could drop us a line at security-officer@FreeBSD.org so we can look into it - thanks.
So far this year FreeBSD has found and fixed several vulnerabilities which exist in all three BSDs, as well as making numerous security fixes to FreeBSD itself (most are in the category of "well, I can't think of any way that would ever be a security problem, but I suppose it could be one in someone's weird setup, and it's still a bug").
Yes, it's possible, but a) then they wouldn't be releasing BSD-licensed code, but proprietary code, and b) I can assure you they're not going to be doing that:-)
Ignoring the insult to Nik, who has done a lot more for the free software community than you probably realise, I'll assume you were serious in your question.
@freebsd.org email addresses are only available to FreeBSD committers - you generally have to prove yourself by doing something really worthwhile (e.g. submitting lots of ports, writing documentation, writing or maintaining nifty code, etc) before you're offered committer status.
You know, I don't want to sound like I'm knocking OpenBSD - I'm not - but it kind of irks me to see this particular myth perpetuated. The OpenBSD code audit wasn't really "line by line" and they didn't rebuild the OS "from the ground up". What they did was analyse the source code for lots of different types of mistake - if it was line by line, then they presumably wouldn't still be fixing bugs (when the FreeBSD auditing project started up we found quite a few minor bugs, as well as one or two more serious ones, which OpenBSD had missed so far).
> Does this mean the code for each *BSD will eventually merge? It's > always bothered me that 4.4BSD-Lite forked in the first place.
I don't know about merging - the personality differences between certain of the project leaders, not to mention so much code divergence (lots of minor changes) may prevent that from ever becoming a reality - but the three projects are certainly converging. FreeBSD is being ported to new platforms, NetBSD and FreeBSD are both gaining new "integrated crypto" features and increasing the attention to security, OpenBSD and NetBSD are working on SMP support, etc.
There's a fair bit of parallel effort going on, but on the other hand there's an awful lot of code sharing. e.g. the USB stack is shared between at least NetBSD and FreeBSD, with fixes and enhancements going in both directions, OpenBSD and NetBSD regularly port drivers from FreeBSD, etc.
I'm not sure the differences are as large as you claim. On the issue of crypto, FreeBSD 4.0 includes: IPSEC OpenSSL OpenSSH Kerberos 4 and 5 Support for link-level encryption on ethernet/wireless cards that support it etc. About the only extra "crypto" thing I could think of that openbsd has is encrypted swap, which is planned for FreeBSD too. Is there something I've missed?
Re:Source is free, but NSA evaluation process IS N
on
TrustedBSD Announced
·
· Score: 1
Actual certification of an OS costs vast amounts of money (millions) but that doesn't mean you can't make a product TARGETTED at those criteria - which would be almost as useful (e.g. filesystem ACLs have uses for ordinary users, not just government agencies)
Slashdot Mirror
It was switched to a different machine, because the usual ftp.freebsd.org is hosted by lightning who have a fucked network.
As bad as Netscape is, it's maintained a lot better for Linux than it is for other UNIX platforms (at least on i386).
You also seem to misunderstand the idea of Linux binary compatability -- it's not "emulation", the binaries run *natively*. The BSD kernel reconfigures itself to appear like a Linux kernel to the Linux binaries, and everything runs just as if it was on a Linux machine, on the bare hardware. Therefore Linux binaries run at full-speed, just like native BSD binaries. It's very cool - in fact, I'm typing this as we speak in a Linux mozilla daily build on my FreeBSD box.
There's a good entry in the FreeBSD handbook about this if you're interested in more details.
This has been relevant in the past, but it's basically a non-issue at the present time. For example, FreeBSD has blanket export permission for all things crypto thesedays.
One of the goals of the TrustedBSD project is to add POSIX capabilities to FreeBSD. A useful capability is CAP_NET_BIND_SERVICE, which allows daemons to be bound to low (1024) ports.
So don't worry, FreeBSD will soon give everyone in the world (not just Christians) the power to bind the daemons on their system.
Stay tuned. FreeBSD 5.0-CURRENT has working sftp support (as does OpenBSD, where the code came from). It will likely be backported to 4.1.1-STABLE in a week or two.
Well, as much as I hate to say something which might dispel your impression that BSD developers are amazing :-) this was actually very simple to achieve and involved REMOVING code which was keeping RSA *out* of the US version.
International folks have had real RSA since 4.0-RELEASE (and this was enabled by default on the releases by some third party CD distributors) - but as of 4.1.1 the main BSDi release of FreeBSD will have it enabled for all users.
The native OpenSSL RSA code was added back to OpenSSL (international people have already been using this since the beginning), meaning OpenSSH can now speak SSHv1 out of the box where before you had to install the rsaref library separately, and not everyone was allowed to use it.
The biggest upshot is that a default FreeBSD installation will come up running OpenSSH and speaking both SSH1 and SSH2 protocols when you reboot it after completeing the initial installation.
No-one's trying to claim this is some kind of breakthrough. IPv6 has been available on *BSD platforms for 3-4 years too, and for example the standard FreeBSD 4.0 from earlier this year was fully IPv6-enabled (and the more recent 4.1 even more so :-).
Not sure what your point was?
Nope, thats not what I was talking about. It is *a* problem with sprintf(), but it can be protected against without using snprintf(). Missing format strings are different.
Actually, what I meant was in reference to theformat string vulnerability: sprintf(buf, argv[1]) instead of sprintf(buf, "%s", argv[1]) kind of thing. Contrary to popular belief, sprintf() can be used safely as long as you check the length of your string before using it. It's often easiest to just use snprintf(), which makes for easier auditing and so on, but sprintf() isn't always wrong.
Yes, both FreeBSD and OpenBSD did a pro-active sweep several months ago to identify and fix any of these problems. We didn't find any security problems, but there were a few non-exploitable bugs in unprivileged apps which were caught (fixed prior to 4.1-RELEASE).
Of course, if you run third party software which we haven't yet audited then you might be vulnerable, but thats always the risk you take. FreeBSD is slowly working through the ports collection to try and audit this code.
With almost 3800 ports it's a large task, but it's bearing a lot of fruit - in fact we're discovering security problems in third party code at a faster rate than I have time to keep up with and write ports advisories for. Ultimately everyone who uses UNIX software will benefit from this work.
Kris Kennaway
FreeBSD Security Officer team
The BSD-derived FTP server had a problem of this class which was discovered and fixed a few months ago. However FreeBSD fixed it in our version back in 1996, so we were exempt from the ensuing security brouhaha :-)
Kris Kennaway
FreeBSD Security Officer team
It was something which was never an issue to begin with, because the code was written correctly from the start. "Format string vulnerabilities" result from improper use of functions like syslog() and sprintf(), and for whatever reason our code just didnt have any serious problems there.
Kris Kennaway
FreeBSD Security Officer team
Both FreeBSD and OpenBSD did a full audit sweep of our respective source trees soon after the class of "format string vulnerabilities" were discovered.
;-) suffered, and apparently there are lots of other setuid binaries on Linux vulnerable to this local exploit). Make of this what you will :-)
We didn't find anything serious, although there were a few in non-setuid binaries which of course aren't a security problem unless you use them in a weird way (like hooking them up to unfiltered network input or something). OpenBSD had a hole in setproctitle() in their ftpd a few months back, IIRC. Most of the changes we made were for "correctness" rather than a demonstrable security benefit.
By contrast, most Linux distros apparently have these problems (rpc.statd was one, as well as the ftpd problem which just about everyone (except FreeBSD
Kris Kennaway
FreeBSD Security Officer team
I think your first sentence was correct :-)
The TCP part of TCP/IP works pretty well, the
problems are with the IP(v4) part which is running out of address space etc. Those are the issues IPv6 addresses.
Like it or not, TCP and UDP are goign to be
around for a very long time, so the layer 3 protocol they run over damn well better support them.
Oops, slashdot ate my cookie. The parent comment was posted by me (I don't like to hide as an AC)
3.5 is the final scheduled release on the 3.X branch. The FreeBSD development model has multiple simultaneous branches, on which releases are periodically made as "snapshots" of the branch at that point in time.
:-)
Development on the branches never really stops, although it does slow down considerably once the branch reaches end-of-life (as 3.X is about to do). Heck, there are still even occasional commits to 2.2.8-STABLE and even 2.1.7.1-STABLE
> FBSD is still probably vulrable to a procfs
> exploit (although it hasn't been written yet)
Hrumph - there's nothing like jumping to conclusions. Do you really think FreeBSD coders are idiots and don't know how to fix bugs when they see them?
IIRC, OpenBSD was just as vulnerable to the problem as FreeBSD if you enabled procfs, the only difference being they didn't enable it in the default kernel.
Just to clarify some of your comments:
Actually, OpenBSD *does* ship lynx in the base system (what's more, it was vulnerable to some of the recent security holes), as well as other stuff like apache.
As of 4.0-RELEASE (which came out in March), FreeBSD ships OpenSSH and OpenSSL in the base system (even on CD). This was shortly after the first OpenBSD release which also included OpenSSH, IIRC. NetBSD also ships OpenSSL (and they pre-dated FreeBSD in this regard, I believe).
Finally, as one of the FreeBSD Security Officers I'm not sure what you're talking about WRT "the ammount of exploits for the -current release" - if these really do exist (and I'd be surprised) then we certainly haven't been informed of them.
What there *has* been lately is a lot of FUD on Bugtraq about "FreeBSD is probably vulnerable to this, but I didn't check" and so forth, but not a lot of content (well, there were a couple of vulnerabilities which applied to the other BSDs as well). If you have anything solid to point to here I'd appreciate it if you could drop us a line at security-officer@FreeBSD.org so we can look into it - thanks.
So far this year FreeBSD has found and fixed several vulnerabilities which exist in all three BSDs, as well as making numerous security fixes to FreeBSD itself (most are in the category of "well, I can't think of any way that would ever be a security problem, but I suppose it could be one in someone's weird setup, and it's still a bug").
Yes, it's possible, but a) then they wouldn't be releasing BSD-licensed code, but proprietary code, and b) I can assure you they're not going to be doing that :-)
Ignoring the insult to Nik, who has done a lot more for the free software community than you probably realise, I'll assume you were serious in your question.
@freebsd.org email addresses are only available to FreeBSD committers - you generally have to prove yourself by doing something really worthwhile (e.g. submitting lots of ports, writing documentation, writing or maintaining nifty code, etc) before you're offered committer status.
You know, I don't want to sound like I'm knocking OpenBSD - I'm not - but it kind of irks me to see this particular myth perpetuated. The OpenBSD code audit wasn't really "line by line" and they didn't rebuild the OS "from the ground up". What they did was analyse the source code for lots of different types of mistake - if it was line by line, then they presumably wouldn't still be fixing bugs (when the FreeBSD auditing project started up we found quite a few minor bugs, as well as one or two more serious ones, which OpenBSD had missed so far).
> Does this mean the code for each *BSD will eventually merge? It's
> always bothered me that 4.4BSD-Lite forked in the first place.
I don't know about merging - the personality differences between certain
of the project leaders, not to mention so much code divergence (lots of
minor changes) may prevent that from ever becoming a reality -
but the three projects are certainly converging. FreeBSD is being ported
to new platforms, NetBSD and FreeBSD are both gaining new "integrated crypto"
features and increasing the attention to security, OpenBSD and NetBSD
are working on SMP support, etc.
There's a fair bit of parallel effort going on, but on the other hand
there's an awful lot of code sharing. e.g. the USB stack is shared between
at least NetBSD and FreeBSD, with fixes and enhancements going in both
directions, OpenBSD and NetBSD regularly port drivers from FreeBSD, etc.
I'm not sure the differences are as large as you claim. On the issue of crypto, FreeBSD 4.0 includes: IPSEC OpenSSL OpenSSH Kerberos 4 and 5 Support for link-level encryption on ethernet/wireless cards that support it etc. About the only extra "crypto" thing I could think of that openbsd has is encrypted swap, which is planned for FreeBSD too. Is there something I've missed?
Actual certification of an OS costs vast amounts of money (millions) but that doesn't mean you can't make a product TARGETTED at those criteria - which would be almost as useful (e.g. filesystem ACLs have uses for ordinary users, not just government agencies)