<RANT>
The only reason FreeBSD even needs to run anything in "Linux emulation mode" is for software where the coders are either so shortsighted that the only release Linux binaries, or the source code is so Linux-centric that porting isn't worth the effort. </RANT>
Nitrous Oxide is N2O, the plasmoid in the microwave produce NO2, or nitrogen oxide. Feel free to inhale this gas, but you won't get the effect you were expecting:-)
This topic was hashed to death in bofhnet a few weeks ago. There are good reasons to buy commercial firewalls:
If you are hit by a bus, they can find somebody else who knows the product.
By installing a well-known commercial product, you are less likely to be sued/fired when the firewall is hacked.
If your time is worth anything, buying a $25K firewall will be cheaper in the long run.
Commercial vendors sell tech support, so if something breaks during your once in a lifetime vacation to Aruba, you won't be called back to the office to fix the firewall.
If you aren't doing this to save money, then you might just want to try to find small form-factor hardware that will run Secure Computing's Sidewinder firewall.
Sidewinder is based on a customized version of BSD, runs on normal PC hardware, and has most of the features you'd put in if you designed your own firewall, plus it comes with a GUI so you can delegate maintenance to lesser mortals. But Sidewinder isn't cheap.
I enjoy building my own OpenBSD firewalls, but for nearly any commercial purpose, I purchase commercial firewall products from major vendors.
One of the advantages of custom building a firewall using *BSD with IP-Filter is that you can load your own protocol-aware and 'application proxy' software on the device, where the PIX is strictly a stateful-inspection packet filter with some minimal protocol awareness for 'fixup', and that sometimes doesn't even work correctly, such as their FTP fixup hole.
The disadvantage to the Cisco PIX is that the OS is not well known and not available for download, so you will never know what exploitable holes exist. Meanwhile, Cisco engineers and any uber-crackers who have obtained copies of PIX source code can root you at will:-)
Sure, BSD has had a few holes, but most of those are related to software you don't need installed on your firewall. Or you load OpenBSD, and eliminate the majority of OS exploits from the problem pool.
This is where you take a page from the Canadian's play book, and register your DirecTV receiver in a state that doesn't have any interesting major league teams.
If your satellite provider believes you live in Alaska, they will not blackout any Arizona games...
I'm working on this now, there really isn't much to it. It's actually easier to code than SOCKS support.
The 'right' way to solve this problem is to put a Jabber server on your corporate extranet, allow only inside users to connect to the server on 5222/5223, and allow outbound connections to other jabber servers (and dialback from them on 5269).
Bad code is bad code, diversity is a red herring.
on
New Linux Worm
·
· Score: 2
It's not a question of diversity. The real issue is that BIND is poorly written, and by design is more susceptible to root holes than DJBDNS.
Competing apps should continue to compete, but badly written monolithic software that requires root access and is a long-running source of exploits (BIND and sendmail come to mind) should be gotten rid of, not kept around for the sake of 'diversity'.
The reason that DJBDNS is not exploited where BIND is is not because one is more popular, but because BIND is written so badly that nothing short of throwing it away and starting from the ground up (as DJBDNS has done) will fix it.
While OpenBSD ships with BIND, it was never vulnerable to worms of this nature, because the OpenBSD team realizes that BIND is badly written code, and install it in such a way (chroot and setuid to a normal user) that an exploit of BIND will not yield a remote root hole.
It's a different philosophy, just a small part of why Linux distros are vulnerable where other operating systems are not...
Re:no, tripwire should not be a necessity
on
New Linux Worm
·
· Score: 2
In a perfect world, all software would be released with no unknown bugs. Consider the SSH holes over the last couple of years.
This is not a perfect world. Just because you do not know of any exploitable root holes in sshd, telnetd, apache, etc today, does not mean that one will not be found tomorrow.
It is not uncommon for exploits to be discovered and traded in the black-hat community for days, months or even years before being made public.
To believe that you will not be targeted by 'real crackers' because you are not an interesting target is a naive and dangerous assumption.
Re:Use DJBDNS instead of BIND.
on
New Linux Worm
·
· Score: 2
Seriously, it's like it was coded to stress-test syslog so it has zero error checking...
IIRC, Dan really dislikes syslog, so this may not be far from the truth.
Re:Why exactly are BIND and Sendmail known for hol
on
New Linux Worm
·
· Score: 5
I replace BIND with DJBDNS, and Sendmail with Qmail.
Both Sendmail and BIND suffer from the same basic problem- they are huge monolithic programs that must be executed as root to perform their intended duties.
From the Qmail web site:
Why is qmail secure?
The reason I started the qmail project was that
I was sick of the security holes in sendmail and other MTAs.
Here's what I wrote in December 1995:
Every few months CERT announces Yet Another Security Hole In
Sendmail---something that lets local or even remote users take complete
control of the machine. I'm sure there are many more holes waiting to be
discovered; sendmail's design means that any minor bug in 41000 lines of
code is a major security risk. Other popular mailers, such as Smail, and
even mailing-list managers, such as Majordomo, seem just as bad.
I followed seven fundamental rules in the design and implementation of qmail:
Programs and files are not addresses. Don't treat them as addresses.
sendmail treats programs and files as addresses.
Obviously random people
can't be allowed to execute arbitrary programs or write to arbitrary files,
so sendmail goes through horrendous contortions trying to keep
track of whether a local user was ``responsible'' for an address.
This has proven to be an unmitigated disaster.
In qmail, programs and files are not addresses.
The local delivery agent, qmail-local,
can run programs or write to files as directed by
~user/.qmail, but it's always running as that user.
(The notion of ``user'' is configurable, but root is never a user.
To prevent silly mistakes,
qmail-local makes sure that
neither ~user nor ~user/.qmail is world-writable.)
Security impact:.qmail,
like.cshrc and.exrc and various other files,
means that anyone who can write arbitrary files as a user can execute
arbitrary programs as that user. That's it.
Do as little as possible in setuid programs.
A setuid program must operate in a very dangerous environment:
a user is under complete control of
its fds, args, environ, cwd, tty, rlimits, timers, signals, and more.
Even worse,
the list of controlled items varies from one vendor's UNIX to the next,
so it is very difficult to write portable code that cleans up everything.
Of the twenty most recent sendmail security holes,
eleven worked only because the entire sendmail system is setuid.
Only one qmail program is setuid: qmail-queue.
Its only purpose is to add a new mail message to the outgoing queue.
Do as little as possible as root.
The entire sendmail system runs as root,
so there's no way that its mistakes
can be caught by the operating system's built-in protections.
In contrast,
only two qmail programs, qmail-start and qmail-lspawn, run as root.
Move separate functions into mutually untrusting programs.
Even if qmail-smtpd, qmail-send, qmail-rspawn, and qmail-remote
are completely compromised,
so that an intruder has control over the
qmaild, qmails, and qmailr accounts and the mail queue,
he still can't take over your system.
None of the other programs trust the results from these four.
In fact, these programs don't even trust each other.
They are in three groups:
qmail-smtpd, which runs as qmaild;
qmail-rspawn and qmail-remote, which run as qmailr;
and qmail-send, the queue manager, which runs as qmails.
Each group is immune from attacks by the others.
(From root's point of view,
as long as root doesn't send any mail,
only qmail-start and qmail-lspawn are security-critical.
They don't write any files or start any other programs as root.)
Don't parse.
I have discovered that
there are two types of command interfaces in the world of computing:
good interfaces and user interfaces.
The essence of user interfaces is parsing:
converting an unstructured sequence of commands,
in a format usually determined more by psychology than by solid engineering,
into structured data.
When another programmer wants to talk to a user interface,
he has to quote:
convert his structured data into an unstructured sequence of commands
that the parser will, he hopes,
convert back into the original structured data.
This situation is a recipe for disaster.
The parser often has bugs:
it fails to handle some inputs according to the documented interface.
The quoter often has bugs:
it produces outputs that do not have the right meaning.
Only on rare joyous occasions does it happen that
the parser and the quoter both misinterpret the interface in the same way.
When the original data is controlled by a malicious user,
many of these bugs translate into security holes.
Some examples:
the Linux login -froot security hole;
the classic find | xargs rm security hole;
the Majordomo injection security hole.
Even a simple parser like getopt
is complicated enough for people to screw up the quoting.
In qmail, all the internal file structures are incredibly simple:
text0 lines beginning with single-character commands.
(text0 format means that
lines are separated by a 0 byte instead of line feed.)
The program-level interfaces don't take options.
All the complexity of parsing RFC 822 address lists and rewriting headers
is in the qmail-inject program,
which runs without privileges and is essentially part of the UA.
Keep It Simple, Stupid
Automatic upgrade pitfalls
on
New Linux Worm
·
· Score: 1
Great.
Now all I need to do is hack the DNS entry for the upgrade server, and watch the users connect and automagically r00t themselves with my trojaned binaries.
The answer to this problem is of course, public key security. Sort of like the Microsoft signing keys that were obtained illegitimately just this week?
Even Microsoft doesn't automatically install security updates, their 'critical update notifier' simply tells users that an upgrade is needed, you still need to take positive action to install patches.
Use DJBDNS instead of BIND.
on
New Linux Worm
·
· Score: 5
There is seldom any good reason to run BIND, when you can get a free secure replacement from Dan Bernstein.
There are way to many machines running full services when only one or two listening processes are really needed, if that.
Centralized Authentication. Do you need a cluster of 'authentication servers' so all the various systems can use a single authenticatior?
Single Sign-On. Do you need users to authenticate once at the beginning of the session, and be able to access distributed resources without having to re-authenticate for each server/service?
Password Replacement Do you need to eliminate insecure reusable passwords and provide a multi-factor (Something you know, something you have, something your are) authentication mechanism?
There are various solutions that solve some or all of these problems. As it happens, I consult on these issues for a living.
There is not more buzz about it because the use of pure compressed air for an automobile is not practical.
Simply put, you cannot store enough energy using atmospheric air under pressure in lightweight tanks.
There are viable means for using compressed gases to power a vehicle, such as hydrogen fuel cells. But using strictly the energy from releasing compressed atmospheric air is not going to cut it.
Right. 10% of your paycheck adds up to 6 months pay after five years. Then you spend most of that to make a down payment on a house, and start over again.
As I said, don't think "half my year salary in the bank", think "enough to survive for three months without being out on the street, starving and homeless".
Or if you like math:
cushion=(three months rent) + (three months insurance[health,car,etc]) + (three months utilities) + (three months food).
And remember, that's in addition to anything you have in stocks, options, or other risky investments.
Everything I write will compile and run exactly the same on OpenBSD, NetBSD, FreeBSD, and Solaris.
If only commercial application developers would write good, portable code, and if only freeware/shareware/GNU programmers would stop writing Linux-centric software.
It's amazing how many unneeded Linuxisms I find in free software, from Makefiles that won't work without GNU make to install scripts that expect/bin/sh to be BASH. It's sad, really.
Making it easier to run Linux binaries on BSD systems makes it that much less likely for software vendors to produce native BSD binaries.
I'd rather see the effort spent on 'Binary compatibility to run Linux apps' be used to encourage vendors to produce native BSD binaries.
Some might claim that this shows the technical superiority of BSD, but in my opinion Linux emulation is harmful to the future of BSD operating systems.
I assume you don't have a family, rent, or student loan debt to pay off. It's unrealistic to assume that anybody can put aside six month's pay into a low-risk minimal-interest account and never touch it.
I have 3-4 paycheck's worth in the stock market (two month's pay) and enough savings beyond that so I can survive three months with zero income, assuming I don't mind living on macaroni and cheese and switching back to domestic beer.
A better rule:
Keep enough savings to 'coast' for a month at your current standard of living, or three months if you cut out all non-essentials.
If you carry credit card debt, and work for a dot com, you are one of the few people who can actually benefit from those 'credit protection plan' offers that cover the minimum payment if you are laid off.
In most US states, in most any industry, the who concept of "two week's severance pay" (when fired but not "for cause") and "two weeks notice" when leaving a job are a tradition. It is not a law, it is politeness, good etiquette.
At my previous job, it was an unwritten departmental policy that, with rare exceptions, anybody giving their two weeks notice would be asked to leave at the end of that day. I don't know if they still got two weeks pay, but I doubt it.
That was more a symptom of the incredible arrogance of the CTO than anything else.
Generally, the "signing bonus" is yours to keep unless you voluntarily quit, or perhaps if you are terminated "for cause". I've heard of places making the bonus dependent on successfully passing a drug test, which really just means you are selling your urine for a very nice price.
He never signed the offer letter, was never an employee, and was paid zip.
The self-centered (and immoral) thing to do would have been to take his accumulated vacation time at the government contractor job, so when this gig vaporized he would still have a job to go back to.
The only moral I can find in this story is this- Ask for a signing bonus, and make sure the check clears before you quit your old job:-)
I've only seen the "conduct unbecoming of" codes in private schools, not public.
Attending a private school is a voluntary act, they can expel/suspend/punish the student for whatever they choose, no civil rights issues there.
Attending a public school is not voluntary, and being government run, they must respect civil rights. They can usurp some of your rights while on school grounds, but that's it.
I assume that when you say "in Canada, our Supreme Court has ruled that students in school have no right to privacy, nor do they have unrestricted free speech." you mean in school. Juveniles do indeed have the same protections against government attacks on the to privacy and free speech when they are at home.
That is, when a student is at home, their parents are free to intrude on their privacy and free speech, but your public school's teachers cannot control what you do at home.
Slashdot Mirror
The competitors themselves are very much restricted in weapons design, resulting in very wimpy 'bots that seldom do any real damage.
We need the challenges of Robot Wars with the design rules of Battlebots.
There is even an Official Port of Sun's JDK. It's been covered in a Slashdot article in the past.
<RANT>
The only reason FreeBSD even needs to run anything in "Linux emulation mode" is for software where the coders are either so shortsighted that the only release Linux binaries, or the source code is so Linux-centric that porting isn't worth the effort.
</RANT>
Nitrous Oxide is N2O, the plasmoid in the microwave produce NO2, or nitrogen oxide. Feel free to inhale this gas, but you won't get the effect you were expecting :-)
If you aren't doing this to save money, then you might just want to try to find small form-factor hardware that will run Secure Computing's Sidewinder firewall.
Sidewinder is based on a customized version of BSD, runs on normal PC hardware, and has most of the features you'd put in if you designed your own firewall, plus it comes with a GUI so you can delegate maintenance to lesser mortals. But Sidewinder isn't cheap.
I enjoy building my own OpenBSD firewalls, but for nearly any commercial purpose, I purchase commercial firewall products from major vendors.
The disadvantage to the Cisco PIX is that the OS is not well known and not available for download, so you will never know what exploitable holes exist. Meanwhile, Cisco engineers and any uber-crackers who have obtained copies of PIX source code can root you at will :-)
Sure, BSD has had a few holes, but most of those are related to software you don't need installed on your firewall. Or you load OpenBSD, and eliminate the majority of OS exploits from the problem pool.
If your satellite provider believes you live in Alaska, they will not blackout any Arizona games...
The 'right' way to solve this problem is to put a Jabber server on your corporate extranet, allow only inside users to connect to the server on 5222/5223, and allow outbound connections to other jabber servers (and dialback from them on 5269).
Competing apps should continue to compete, but badly written monolithic software that requires root access and is a long-running source of exploits (BIND and sendmail come to mind) should be gotten rid of, not kept around for the sake of 'diversity'.
The reason that DJBDNS is not exploited where BIND is is not because one is more popular, but because BIND is written so badly that nothing short of throwing it away and starting from the ground up (as DJBDNS has done) will fix it.
It's a different philosophy, just a small part of why Linux distros are vulnerable where other operating systems are not...
This is not a perfect world. Just because you do not know of any exploitable root holes in sshd, telnetd, apache, etc today, does not mean that one will not be found tomorrow.
It is not uncommon for exploits to be discovered and traded in the black-hat community for days, months or even years before being made public.
To believe that you will not be targeted by 'real crackers' because you are not an interesting target is a naive and dangerous assumption.
IIRC, Dan really dislikes syslog, so this may not be far from the truth.
Both Sendmail and BIND suffer from the same basic problem- they are huge monolithic programs that must be executed as root to perform their intended duties.
From the Qmail web site:Why is qmail secure? The reason I started the qmail project was that I was sick of the security holes in sendmail and other MTAs. Here's what I wrote in December 1995:
As it turned out, fourteen security holes were discovered in sendmail in 1996 and 1997.I followed seven fundamental rules in the design and implementation of qmail:
sendmail treats programs and files as addresses. Obviously random people can't be allowed to execute arbitrary programs or write to arbitrary files, so sendmail goes through horrendous contortions trying to keep track of whether a local user was ``responsible'' for an address. This has proven to be an unmitigated disaster.
In qmail, programs and files are not addresses. The local delivery agent, qmail-local, can run programs or write to files as directed by ~user/.qmail, but it's always running as that user. (The notion of ``user'' is configurable, but root is never a user. To prevent silly mistakes, qmail-local makes sure that neither ~user nor ~user/.qmail is world-writable.)
Security impact: .qmail,
like .cshrc and .exrc and various other files,
means that anyone who can write arbitrary files as a user can execute
arbitrary programs as that user. That's it.
A setuid program must operate in a very dangerous environment: a user is under complete control of its fds, args, environ, cwd, tty, rlimits, timers, signals, and more. Even worse, the list of controlled items varies from one vendor's UNIX to the next, so it is very difficult to write portable code that cleans up everything.
Of the twenty most recent sendmail security holes, eleven worked only because the entire sendmail system is setuid.
Only one qmail program is setuid: qmail-queue. Its only purpose is to add a new mail message to the outgoing queue.
The entire sendmail system runs as root, so there's no way that its mistakes can be caught by the operating system's built-in protections. In contrast, only two qmail programs, qmail-start and qmail-lspawn, run as root.
Even if qmail-smtpd, qmail-send, qmail-rspawn, and qmail-remote are completely compromised, so that an intruder has control over the qmaild, qmails, and qmailr accounts and the mail queue, he still can't take over your system. None of the other programs trust the results from these four.
In fact, these programs don't even trust each other. They are in three groups: qmail-smtpd, which runs as qmaild; qmail-rspawn and qmail-remote, which run as qmailr; and qmail-send, the queue manager, which runs as qmails. Each group is immune from attacks by the others.
(From root's point of view, as long as root doesn't send any mail, only qmail-start and qmail-lspawn are security-critical. They don't write any files or start any other programs as root.)
I have discovered that there are two types of command interfaces in the world of computing: good interfaces and user interfaces.
The essence of user interfaces is parsing: converting an unstructured sequence of commands, in a format usually determined more by psychology than by solid engineering, into structured data.
When another programmer wants to talk to a user interface, he has to quote: convert his structured data into an unstructured sequence of commands that the parser will, he hopes, convert back into the original structured data.
This situation is a recipe for disaster. The parser often has bugs: it fails to handle some inputs according to the documented interface. The quoter often has bugs: it produces outputs that do not have the right meaning. Only on rare joyous occasions does it happen that the parser and the quoter both misinterpret the interface in the same way.
When the original data is controlled by a malicious user, many of these bugs translate into security holes. Some examples: the Linux login -froot security hole; the classic find | xargs rm security hole; the Majordomo injection security hole. Even a simple parser like getopt is complicated enough for people to screw up the quoting.
In qmail, all the internal file structures are incredibly simple: text0 lines beginning with single-character commands. (text0 format means that lines are separated by a 0 byte instead of line feed.) The program-level interfaces don't take options.
All the complexity of parsing RFC 822 address lists and rewriting headers is in the qmail-inject program, which runs without privileges and is essentially part of the UA.
Keep It Simple, Stupid
Now all I need to do is hack the DNS entry for the upgrade server, and watch the users connect and automagically r00t themselves with my trojaned binaries.
The answer to this problem is of course, public key security. Sort of like the Microsoft signing keys that were obtained illegitimately just this week?
Even Microsoft doesn't automatically install security updates, their 'critical update notifier' simply tells users that an upgrade is needed, you still need to take positive action to install patches.
There are way to many machines running full services when only one or two listening processes are really needed, if that.
In theory, once there is a true MPEG4 standard, hardware decoders should not be far behind.
- Centralized Authentication.
- Single Sign-On.
- Password Replacement
There are various solutions that solve some or all of these problems. As it happens, I consult on these issues for a living.Do you need a cluster of 'authentication servers' so all the various systems can use a single authenticatior?
Do you need users to authenticate once at the beginning of the session, and be able to access distributed resources without having to re-authenticate for each server/service?
Do you need to eliminate insecure reusable passwords and provide a multi-factor (Something you know, something you have, something your are) authentication mechanism?
Simply put, you cannot store enough energy using atmospheric air under pressure in lightweight tanks.
There are viable means for using compressed gases to power a vehicle, such as hydrogen fuel cells. But using strictly the energy from releasing compressed atmospheric air is not going to cut it.
As I said, don't think "half my year salary in the bank", think "enough to survive for three months without being out on the street, starving and homeless".
Or if you like math:
cushion=(three months rent) + (three months insurance[health,car,etc]) + (three months utilities) + (three months food).
And remember, that's in addition to anything you have in stocks, options, or other risky investments.
If only commercial application developers would write good, portable code, and if only freeware/shareware/GNU programmers would stop writing Linux-centric software.
It's amazing how many unneeded Linuxisms I find in free software, from Makefiles that won't work without GNU make to install scripts that expect /bin/sh to be BASH. It's sad, really.
I'd rather see the effort spent on 'Binary compatibility to run Linux apps' be used to encourage vendors to produce native BSD binaries.
Some might claim that this shows the technical superiority of BSD, but in my opinion Linux emulation is harmful to the future of BSD operating systems.
I have 3-4 paycheck's worth in the stock market (two month's pay) and enough savings beyond that so I can survive three months with zero income, assuming I don't mind living on macaroni and cheese and switching back to domestic beer.
A better rule: Keep enough savings to 'coast' for a month at your current standard of living, or three months if you cut out all non-essentials.
If you carry credit card debt, and work for a dot com, you are one of the few people who can actually benefit from those 'credit protection plan' offers that cover the minimum payment if you are laid off.
At my previous job, it was an unwritten departmental policy that, with rare exceptions, anybody giving their two weeks notice would be asked to leave at the end of that day. I don't know if they still got two weeks pay, but I doubt it.
That was more a symptom of the incredible arrogance of the CTO than anything else.
Generally, the "signing bonus" is yours to keep unless you voluntarily quit, or perhaps if you are terminated "for cause". I've heard of places making the bonus dependent on successfully passing a drug test, which really just means you are selling your urine for a very nice price.
The self-centered (and immoral) thing to do would have been to take his accumulated vacation time at the government contractor job, so when this gig vaporized he would still have a job to go back to.
The only moral I can find in this story is this- Ask for a signing bonus, and make sure the check clears before you quit your old job :-)
Attending a private school is a voluntary act, they can expel/suspend/punish the student for whatever they choose, no civil rights issues there.
Attending a public school is not voluntary, and being government run, they must respect civil rights. They can usurp some of your rights while on school grounds, but that's it.
I assume that when you say "in Canada, our Supreme Court has ruled that students in school have no right to privacy, nor do they have unrestricted free speech." you mean in school. Juveniles do indeed have the same protections against government attacks on the to privacy and free speech when they are at home.
That is, when a student is at home, their parents are free to intrude on their privacy and free speech, but your public school's teachers cannot control what you do at home.