Slashdot Mirror

Setting up Linux was like using strong wooden poles to hold the tent, and using OpenBSD was like using steel poles.

Linux + GRSec + RBAC + PIE + SSP + etc etc = much much tougher.

That depends. What OS is it running?

One without current security updates.

One without any security updates that require reboots to become effective. See the difference? On Linux, it's almost exclusively kernel updates that require reboots. And even then, if you've built your own kernel from source, and the problem is in a module, you can usually just patch the code, and modprobe -rv module ; modprobe -v module.
Course, if it's a module you don't use, you can just delete that module, and not load it.
Also, there are kernel patches that make a large percentage of exploits fall over.

That's crap. It dosen't work on SELinux, but may if any bypass-type holes in SELinux show up.

Any complete memory protection/RBAC system can prevent stuff like this (e.g. http://www.grsecurity.org/), but it shouldn't. For example, you can make it impossible to insert kernel modules after startup in grsecurity, but for a long time a 'root only' bug in the kernel allowed you to insert a module and execute it anyway (this may be the same bug, who knows). Good RBAC setups assume root is untrusted.

Not too long ago I ran the discovery and benchmarking on a big project to move the large internet credit card processor I work for to either Xen or VMWare ESX server. From the first benchmark to the last stress test, Xen outperformed and outgunned ESX at every turn. Here's the kicker! We had paid VMWare engineers helping us to configure and tweak the ESX boxes. As for help from Xen? Well, I had the user's manual and a subscription to their mailing list.

Management

Sure, the VMWare servers had nice pretty management tools that were probably a couple hundred yards ahead of Xen's CLI tools, but this company doesn't exactly tolerate idiots. The unix guys here are more than capbable of migrating to Xen, compiled from source with a customized kernel, with no problem. The command line configuration and live migration utilities are more than adequate considering we already have SSH access to the boxes in the back. There was no need to change the firewall configs to allow us VMWare console access or anything.

Performance

I ran series of benchmarks for the following applications: MySQL, Apache, Lighttpd, perl and php. All of the bechmarks were ran on the same hardware, I just re-imaged the two machines multiple times. Xen won in every race. As a matter of fact, on the dual core Opeteron SunFire the Xen vm was a whopping 600 seconds ahead of the VMWare vm at running MySQL's sql-bench suite.

Stability

Xen 3.0 is more stable, IMHO than VMWare. Though neither platform crashed or hosed, the ESX box had a lot of trouble keeping time via ntp and had some problems with disk I/O.

Distrust

I reported the time problem several times to the VMWare techs assigned to our case, and they assured me that it was a host os issue. Funny that this article mentions that ESX < 3 has a problem keeping time with a 2.6 kernel isn't it?

Future

Later this week I'll be recieving the first Intel VT enabled server we purchased. I'll soon see if any OS or any kernel (including GRSec patched) kernels can be booted under Xen. If that is case, my company is likely is to purchase XenSource's commercial products.

[ ] Deny writing to /dev/kmem, /dev/mem, and /dev/port

To some extent I agree with the opening line of the article.

The company that employs me was founded almost entirely, way back in the day, on OSS. It has used BSD and Linux as it's bread and butter every since. Sure, we may have the Win2k exchange server for the bean counter's calendars, but if it makes us money it's platformed on an OSS OS.

Recently, we've come to realize the functionality that we desire in our applications and platforms aren't currently available in Linux, MySQL, Apache, etc. If we were MS based, we would be SOL, and we would have to work inside the box MS build for us. If we were locked into specific vendors, say Win 2003/IIS/Oracle, we would be at the mercy of those companies to provide us, just one of their millions of customers, with the features we need to stay competetive and up to code in the business we do. Since our main business deals with online credit card, check and phone transactions we are under very, very strict security guidelines imposed by various banks, Visa, MasterCard, etc. Without a very significant invenstment in third party software and rude in-house hacks, we would never make the grade on those platforms. Instead we have hired a few C programmers and made some serious contributions to OSS projects like GRSEC. Yes projects such as these are quicker to implent features for companies that sponser them and they are also very quick in support, and if they decide to stop coding one day we still have the source and a few programmers to get the job done. On top of that we are looking at proprietary solutions that stack on top of our OSS platforms such as Emic and PeerFS.

The point is: OSS isn't free, and the TOC of OSS Vs. Proprietary is depndant upon situation. However, when we made platform decisions 10 years ago or so, we didn't know the requirements we would be facing today. Had we chosen the vendor/proprietary platform we would not have had the capabability of not only competing, but remaining ahead of the pack given today's requirements. The flexibility OSS gives to business could be it's biggest selling point. Anyone who is familiar with the HIPAA regulations imposed on health information tech will know that vendors are just too damned slow to keep up with the pace of policy makers. The hospital I was working with the at the time had to spend, quite literally, millions of dollars to migrate it's insurance billing system away from Digital (VMS)* and Microsoft/Citrix just to conform. In the end it's now stuck with HP/UX and AS/400. Another vendor lock-in.

* This always struck me as odd since HP had just bought out Compaq who had bought out Digital at the time.....try getting support for that!

Here, I'll fix it. Your post with clickable links:

For a comparison between Grsecurity and SELinux: click here

They also document and explain many of the issues facing the LSM project as well: here

It will be interesting to see how the Gentoo Hardened Project will respond to this as well as they have done a great deal of work with grsecurity and provided some exceptional Grsecurity documentation (for the 1.9.x series).
Hardened Gentoo
Gentoo Grsecurity Guide

It will be sad to see this project fade away, especially for those needing an expressive security RBAC/MAC/PAX system. Grsecurity, combined with PAX, provided a well rounded security system that was sensible, somewhat easy to learn, and easier to administrate thanks to the powerful gradm Learning capability.

I've tried that exploit on all of my boxes the first time I read about it. However, it always fails, and never works. I am wondering if some of the grsecurity patches are disabling it.

calum@xxx calum $ ./mremap_pte

[+] kernel 2.4.20-gentoo-r9 vulnerable: YES exploitable YES
MMAP #9216 0x43000000 - 0x43001000Segmentation fault

Mar 7 18:49:38 xxx kernel: grsec: From xxx.xxx.xxx.xxx: attempted resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 by (mremap_pte:7672) UID(1000) EUID(1000), parent (bash:26711) UID(1000) EUID(1000)

Anyone know if the grsec stuff is saving me?

Have a look at grsecurity.org sometime. I used to use Lids, but grsec seems to be a fuller option. Same idea though.

http://www.trl.ibm.com/projects/security/ssp/

"GCC extension for protecting applications from stack-smashing attacks"

Btw, this is not a case of 'unsafe' functions at all.

May I also point that programming mistakes become vulnerabilities in most of the situations only because of platform limitation. Even for 'insecure' platforms (like x86 :D), selinux and grsecurity implement some nice protection mechanisms.

Programming errors are supposed to make a program crash. The system should make sure this happens.

Because Linux offers an even greater bang/buck than OS X. It offers better java performance, finer-grained security through such items as the grsecurity packages, and increased data protection through the kernel encryption packages. Yeah, as a desktop OS, OS X is okay looking, but on a server, Linux just blows it away.

I use LEAF, and have since they forked their code from the original "Cop Killer" Dave at linuxrouter.org. The Bering floppy and CD images are the best, with tools like GRSecurity (enhanced kernel security), Shorewall (great tool for configuring ipchains, for every possible setup), FreeS/WAN (IPSEC/VPN tools), and a 2.4 based kernel that works great on a 486. The best thing is the developers over at LEAF, keep their packages current.

At present, I have 6 offices, hanging off this setup, with each one running the VPN daemon as well. There are plans in place (installation stage) to get 6 more internet circuits for the rest of our offices, making making for a total of 12 offices running off this code. It's excellent code, with a very well integrated setup, using standard tools, and gobs of documentation.

The best thing; except for the main office (which uses a P166), everyone else will be running their firewall and VPNs on pentium 100's or 120's, with 24 or 32 megs of ram.

if you're interested in random ISN's I'd suggest you try the grsecurity patch from grsecurity.

it has loads of other interesting functions and the random ISN generator seems to work fine, here's a nmap scan result :

TCP Sequence Prediction: Class=random positive increments
Difficulty=4184073 (Good luck!)
TCP ISN Seq. Numbers: BA77562B B9B190FD BA8C8609 BA3DFEB2 BA92DBDB B9BA515C
IPID Sequence Generation: Randomized