Slashdot Mirror

Here's a short list of Linux flaws that make it look silly:

* /usr/include/linux (come on. honestly.) Lame. Nonstandard. (for the clue-deprived, this means that any code written for linux using the linux/ headers will be incompatible with all other Unix flavors.) Guess what: string.h, types.h, malloc.h, signal.h, and so-on don't belong in a platform-specific include directory. Hope you didn't want to port your code...
* Neither the sigaction manpage nor the signal.h includs indicate what the system defaults are. Of course, they've put signal.h in /usr/include/linux...
* "intro" manpages are a joke. Compare the BSD section 2 intro with the one from Linux.
* file systems mount async by default (power outage and your fs dies)
* Most linux users don't have pubes yet and are intolerably lame (3Y3 4m 1337 H4x0r d00d [uz 3y3 h4v3 L1Nux!)
* Too many things in user space that belong in the kernel (nfs)
* Too many things in the kernel that belong in user space (java)
* No standard distribution. Linux people say this is a good thing? Try writing software or software configuration instructions when you never know how the OS is going to be laid out, or try finding the responsible party for a block of OS code, or try fixing security problems when they arise and you'll see that this is NOT a good thing at all.
* no consistant pronunciation the os'es name (line-ucks? lynn-ucks?)
* svr4? bsd? make up your mind?
* Lame NFS & dd
* #linux, #hack, #linuxwarez...
* New kernel every week that breaks half your applications
* Security flaw/Root compromise of the week (see below)
* glibc? libc? libc5? libc6? glibc2?
* /bin/sh != sh; /bin/sh == bash. Lame. Nonstandard. Result: broken shell scripts and nonportable code.
* /usr/bin/make != make; /usr/bin/make == gmake. Lame. Nonstandard. Same result as above: nonportable code.
* ext2fs
* Linux will mount partitions that are not clean
* can't handle partitions > 2GB (i've hear they finally fixed this one)
* e2fsck deliberatly leaves/creates corrupt files (if there is a block that it duplicate between two files, e2fsck will clone the duplicate (while fsck will remove both files. This can also result in a user gaining unauthorized access to another user's data.))
* it swap likes swap to swap swap too swap often swap
* only allows 128M of swap at a time; for a 1G of swap, you need 8 swap partitions
* can't handle more than 1GB of RAM
* To install Joe's program, you need Bob's kernel hack, but for Bob's kernel hack, you've got to have Suzy's patches, but Suzy's patches only work with a year-old kernel, unless you get Mike's patches to Suzy's patches, but even then, those conflict with Jeff's drivers, which can be resolved only by installing Nancy's patches...
* Can't handle the same IP on more than one interface
* Can't handle large files
* Max file size: 2GB. (*BSD: 4 Terabytes)
* Dynamically linked root shell. Doom!
* lilo! any boot loader that needs to have magic block numbers is wrong
* linux icmp.h is *NOT* unix icmp.h - they're totally incompatible.
* flatfile password files make listing large ftp directories impossible due to huge numbers of flatfile searchces.
* password file can be non-shadowed - encrypted passwords visible to all
* shadow.h! hahahahahahaha!
* Slowass network code
* Did I mention slowass network code?
* Oh, also slowass network code
* Miserably pathetic threading implementation doesn't scale for shit: all threads wake up on signals (stampeding process problem).
* L1nux c0d3rz!
* LILO can't cope with kernels > 1Mb, so the kernel has to be gzipped.
* strfry and memfrob
* Can't cope with hard drives > 32GB
* GPL - a license and a virus
* Fundamental design and direction problems. It turns out that Linus is not the smartest man in the world and the saviour of all mankind.
* OS or religion?
* UNABLE TO LOAD INTERPRETER...memory leak much?
* This is a real Linux error message: Uhhh. NMI recieved. Dazed and Confused. Trying to cope ...such professionalism!
*The GNU su manpage actually says this:
This program does not support a "wheel group" that restricts who can su to super-user accounts, because that can help fascist system administrators hold unwarranted power over other users. ...apparently it's better for any user to attack the root password than to offer added security. Ignorance of security is a common Linux thread.
* vi != vi; vi == vim. vim links to X libraries. Wipe X, and now you can't use vi. Retards.
* Still no USB support in 2000, after NetBSD and FreeBSD have had it for nearly 2 years. So much for the "million geeks" theory of rapid software development.
* Always trying to help you hold your weewee when you're going tinkle.
* No version control used to manage the system.

Sorry, you're just wrong. A one time pad is pure random data. One XORs the data with the message. It is mathematically impossible to decrypt without a copy of the data used, because every possible decryption is equally likely.

Code talkers were speaking a language. Speaking a language in no way can be compared to employing an OTP. Someone not knowing the language could have, in time, learned it through a variety of methods. They just got lucky that the Japanese didn't have time time or the will to do so.

Check out http://pubweb.nfr.net/~mjr/pubs/otpfaq/
for more information.

-j

Here's a short list of Linux flaws that make it look silly:

* /usr/include/linux (come on. honestly.) Lame. Nonstandard. (for the clue-deprived, this means that any code written for linux using the linux/ headers will be incompatible with all other Unix flavors.) Guess what: string.h, types.h, malloc.h, signal.h, and so-on don't belong in a platform-specific include directory. Hope you didn't want to port your code...
* Neither the sigaction manpage nor the signal.h includs indicate what the system defaults are. Of course, they've put signal.h in /usr/include/linux...
* "intro" manpages are a joke. Compare the BSD section 2 intro with the one from Linux.
* file systems mount async by default (power outage and your fs dies)
* Most linux users don't have pubes yet and are intolerably lame (3Y3 4m 1337 H4x0r d00d [uz 3y3 h4v3 L1Nux!)
* Too many things in user space that belong in the kernel (nfs)
* Too many things in the kernel that belong in user space (java)
* No standard distribution. Linux people say this is a good thing? Try writing software or software configuration instructions when you never know how the OS is going to be laid out, or try finding the responsible party for a block of OS code, or try fixing security problems when they arise and you'll see that this is NOT a good thing at all.
* no consistant pronunciation the os'es name (line-ucks? lynn-ucks?)
* svr4? bsd? make up your mind?
* Lame NFS & dd
* #linux, #hack, #linuxwarez...
* New kernel every week that breaks half your applications
* Security flaw/Root compromise of the week (see below)
* glibc? libc? libc5? libc6? glibc2?
* /bin/sh != sh; /bin/sh == bash. Lame. Nonstandard. Result: broken shell scripts and nonportable code.
* /usr/bin/make != make; /usr/bin/make == gmake. Lame. Nonstandard. Same result as above: nonportable code.
* ext2fs
* Linux will mount partitions that are not clean
* can't handle partitions > 2GB (i've hear they finally fixed this one)
* e2fsck deliberatly leaves/creates corrupt files (if there is a block that it duplicate between two files, e2fsck will clone the duplicate (while fsck will remove both files. This can also result in a user gaining unauthorized access to another user's data.))
* it swap likes swap to swap swap too swap often swap
* only allows 128M of swap at a time; for a 1G of swap, you need 8 swap partitions
* can't handle more than 1GB of RAM
* To install Joe's program, you need Bob's kernel hack, but for Bob's kernel hack, you've got to have Suzy's patches, but Suzy's patches only work with a year-old kernel, unless you get Mike's patches to Suzy's patches, but even then, those conflict with Jeff's drivers, which can be resolved only by installing Nancy's patches...
* Can't handle the same IP on more than one interface
* Can't handle large files
* Max file size: 2GB. (*BSD: 4 Terabytes)
* Dynamically linked root shell. Doom!
* lilo! any boot loader that needs to have magic block numbers is wrong
* linux icmp.h is *NOT* unix icmp.h - they're totally incompatible.
* flatfile password files make listing large ftp directories impossible due to huge numbers of flatfile searchces.
* password file can be non-shadowed - encrypted passwords visible to all
* shadow.h! hahahahahahaha!
* Slowass network code
* Did I mention slowass network code?
* Oh, also slowass network code
* Miserably pathetic threading implementation doesn't scale for shit: all threads wake up on signals (stampeding process problem).
* L1nux c0d3rz!
* LILO can't cope with kernels > 1Mb, so the kernel has to be gzipped.
* strfry and memfrob
* Can't cope with hard drives > 32GB
* GPL - a license and a virus
* Fundamental design and direction problems. It turns out that Linus is not the smartest man in the world and the saviour of all mankind.
* OS or religion?
* UNABLE TO LOAD INTERPRETER...memory leak much?
* This is a real Linux error message: Uhhh. NMI recieved. Dazed and Confused. Trying to cope ...such professionalism!
*The GNU su manpage actually says this:
This program does not support a "wheel group" that restricts who can su to super-user accounts, because that can help fascist system administrators hold unwarranted power over other users. ...apparently it's better for any user to attack the root password than to offer added security. Ignorance of security is a common Linux thread.
* vi != vi; vi == vim. vim links to X libraries. Wipe X, and now you can't use vi. Retards.
* Still no USB support in 2000, after NetBSD and FreeBSD have had it for nearly 2 years. So much for the "million geeks" theory of rapid software development.
* Always trying to help you hold your weewee when you're going tinkle.
* No version control used to manage the system.

Truly unbreakable encryption has existed for many years: the one-time pad . The problems of unbreakable encryption aren't the theory, but the practice. (If you want truly secure communications among n people who each transmit x bytes of data through the group each day, how will you securely generate n*(n-1)*x bytes of random data each day, and securely distribute it to each of them?)

With legislation that will soon be passed, all that software will be illegal. If you have something that you wish to keep private in the United States, you should immediately begin distributing OTP's to your friends. Just make sure you do it right.

Here .... http://www.nfr.net/nfr/SYSTEM_NOTES.html#LinuxGene ral

Reminds me of Network Flight Recorder which used to be open source minus the signature files contributed by l0pht which were under copyright. I believe NetworkComputing magazine did a test on IDS systems a while back and found that many were not mature enough to depend on for security. Though allowing people to help with the project will go a long way in keeping it up to date.

MS-Windows version is cashware, UNIX version is downloadable after you fill in a nosy marketing survey ... I mean registration.

Whilst this sounds like a good idea, and can be done using most IDS/firewall combos (e.g. RealSecure from ISS or NFR from... er... NFR, in practice most admins shy away from using it for fear of it being turned against them and their networks (think spoofed attacks that appear to be from the "victim's" business partners).

99.9% of the people who consider putting honeypots on their networks should instead spend that time securing their vunlerable networks, checking for and applying the latest patches, and reading up on security trends and issues.

that said, honeypots are a really cool concept, nevertheless. but a network or security admin needs to focus on more fundamental security issues though. those NT network admins, for instance, should be deploying a second, or third, or fourth firewall on BSDi or Linux, instead of wasting time and compromising their security with a misconfigured NT honeypot. honeypots are best left for IT security research environments, or for people who have too much time to waste.

a notable exception is NAI's Cybercop Sting. Sting emulates Cisco IOS 11.2, Solaris 2.6, and WinNT 4, running common services. with Sting, you can pipe all of your legitimate traffic thrugh Sting, and utilize the excellent logging capabilities of Sting for an added layer of security. additionally, Sting can be, should be, and often is utilized to monitor employees (i.e. internal hacking/cracking attempts). since most of the security incidents will be from internal sources, honeypots are an excellent way to monitor for suspicious LAN activity.

there was an excellent discussion recently of the honeypot concept, with a wide range of opinions and views from all sectors of the Net population, on the Security Focus Incidents mailing list. the thread was entitled "Cracked; rootkit - entrapment question?", and was back in late February and early March.

for those who have more interest in honeypots, check out the following:

To Build a Honeypot - article by Lanace Spitzner

CyberCop Sting - product by NAI

dtk - Fred Cohen's Deception Toolkit

NFR's BackOffice Friendly - product by Marcus Ranum and L0pht

and finally, a cool new product that i saw at RSA2000
ManTrap - product by Recourse Technologies that is based on Solaris 7

Marcus, BSD-phile that he is though, believes that the Linux kernel's packet capture facilities are not and will not be fast enough (at least compared with BSD), so this is not an Officially Blessed Solution (TM).

Good Luck!

Benchmarks: http://www.anzen.com/gif/test-intf47.gif

The full report the benchmarks came from: http://www.anzen.com/research/r esearch_perform.html

An explanation of the problem: http://www.nfr.net /nfr/mail-archive/nfr-users/1999/Feb/0110.html

see the Linux Weekly News' Security page for information on Linux security projects which are already under way:
Secure Linux Projects Bastille Linux
Khaos Linux Secure Linux
Security List Archives
Bugtraq Archive
Firewall Wizards Archive
ISN Archive

Distribution-specific links
Caldera Advisories
Debian Alerts
Red Hat Errata
SuSE Announcements

Miscellaneous Resources
CERT
CIAC
Comp Sec News Daily
Crypto-GRAM
Linux Security Audit Project
OpenSEC
Security Focus
SecurityPortal