Slashdot Mirror
Additional Security in the Linux Kernel?
nyx asks: "Recently, I was looking for some way to improve security on my linux boxes. I found few linux patches like grsecurity, LIDS (now also as Linux Security Module), Medusa DS9.
I'm testing grsecurity (and it's ACLs) now and I'm quite satisfied with it, but I wonder, what are pros and cons of other solutions. Anybody tried them and can share his experience with us?"
You might want to check out Saint Jude - a kernel intrusion detection and response system which detects and blocks 'anomalous' behavior (such as root exploits). The developer first presented it at Defcon 8 and it looked pretty cool. It's been in development for over a year - see its SourceForge page for more.
While we are at the topic of security I was wondering whether there are any similar products to StackGuard (www.immunix.org) available for a newer gcc? StackGuard is commercial and only works with older gcc's. If there were such a thing one could probably do a whole system recompile with it (a la Gentoo). That would beef up the security considerably. The Immunix FormatGuard also looks interesting.
D.
I had a friend who ran all of his INET services through a VMWARE instance on his Linux box. He would get hit by a script kiddie, and then use the ROLLBACK feature to undo the damage. He would patch the hole on the virtual machine and start up the site as if nothing happened.
People often forget that the things that make unix multiuser are great security tools. For example, for local security, people who should be able to run certain suid programs can be put in special groups, and then the admin can chown and chmod the executables appropriately.
Running applications in a chroot'ed environment is also helpful. A bit hard to setup, but once you do it, no problems.
Use tools such as iptables to restrict access. For instance, if you know that all your connections will come from *.host.com, change the rules accordingly.
Kernel patches are ugly. They try to get at the root of the problem, but they miss it completely.
The point is that vulnerable code is written by bad coders, who for some unknown reasons think that C is the best language in the universe. Clearly, they can't handle the power that C gives them and should use languages that provide memory handling for them.
BTW,it's theoretically proven that security provided by Discretory Access Control systems (in which ACL's and unix protection schemes belong to) is algoritmically unprovable - you cannot deduct that system is secure based on system and DAC rules. ... - it's also a nonreliable means of security.
That proof is possible if are using mandatory access control or may be other security means.
So DAC are not only pain in the
Isn't this ingenious? Taking potshots at Linux by appearing to support it? ...clients are willing to reduce their servers' feature set, flexibility, and ease of maintainence by switching from Win2k...
I won't rehash the manyfold reasons you're wrong about those assertions (it's been discussed to death already), but I will point out that you're wrong, and you're just trolling. Knock it off.
Besides, while Linux's security is excellent, it can (and should) be improved. It's good, but by no means perfect. (It's much better than anything M$ can put out, though.)
o/~ All God's children shall be free in Pirates of the Caribbean, when we reach that Magic Kingdom in the sky... o/~
> go for an operating system controlled by one company, who knows what their code does, and how to fix it if it goes wrong. The only option, in that case, is Microsoft.
Er... or Apple?
Yeah. Or, for that matter, RedHat.
And with RedHat (or any of the other linux vendors), not only do they know what their code does, but there are also thousands of programmers scattered around the world who know a lot about it.
So if you have a problem, you don't have to beg and plead with a disinterested CS department of a giant corporation. You don't even have to deal with your vendor.
If it's a small problem, you can probably hire one or two of the linux hackers at your local college. For bigger projects that take experience, you can hire a few of the local linux professionals.
You'll be up and running in far less time than it takes to persuade Microsoft to support your needs.
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
Read about it in the RELEASE-NOTESe ta/limbo/en/os/i386/RELEASE-NOTES
ftp://videl.ics.hawaii.edu/mirrors/redhat/linux/b
I say forget trying to patch up Linux, or OpenBSD and its exploitable SSH... try archetectures like the mac for trusted web servers taht are unbreakable based on historical evidence.
:
The MacOS running WebStar as a server has never been exploited.
In fact in the entire securityfocus (bugtraq) database history there has never been a Mac exploited over the internet remotely.
That is why the US Army gave up on MS IIS and got a Mac with WebStar.
I am not talking about BSD derived MacOS X (which already had a couple of exploits) I am talking about Mac OS 9 and earlier.
Why is is hack proof? These reasons
1> No command shell. No shell means no way to hook or intercept the flow of control with many various shell oriented tricks found in Unix or NT
2> No Root user. All mac developers know their code is always running at root. Nothing is higher (except undocumented microkernel stufff where you pass Gary Davidians birthday into certain registers and make a special call). By always being root their is no false sense of security.
3> Pascal strings. ANSI C Strings are the number one way people exploit Linux and Wintel boxes. The mac avoids C strings historically in most of all of its OS. In fact even its roms originally used Pascal strings. As you know pascal strings are faster than C (because they have the length delimiter in the front and do not have to endlessly hunt for NULL), but the side effect is less buffer exploits.
4> Stack return address positioned in safer location than intel. Buffer exploits take advantage of loser programmers lack of string length checking and clobber the return address to run thier exploit code instead. The Mac places return address infornt of where the buffer would overrun. Much safer.
5 : Macs running Webstar have ability to only run CGI placed in correct lodirectoy cation and correctly file typed.
6> Macs never run code ever merely based on how a file is named. ",exe" suffixes mean nothing. For example the file type is 4 characters of user-invisible attributes, along wiht many other invisible attributes, but these 4 bytes cannot be set by most tool oriented utilities that work with data files. For ecxample file copy utilities preserve launchable file-types, but JPEG MPEG HTML TXT etc oriented tools are physically incapable of creating an executable file. the file type is not set to executable for hte hackers needs. In fact its even more secure than that. A mac cannot run a program unless it has TWO files. The second file is an invisible file associated with the data fork file and is called a resource fork. EVERY mac program has a resource fork file containing launch information. It needs to be present. Typically JPEG, HTML, MPEG, TXT, ZIP, C, etc are merely data files and lack resource fork files, and even if the y had them they would lack launch information. but the best part is that mac web programs and server tools do not create files with resource forks usually.. TOTAL security.
7> There are less macs, though there are huge cash prizes for craking into a MacOS based WebStar server. Less macs means less hacvker interest, butthere are millions of macs sold, and some of the most skilled programmers are well versed in systems level mac engineering and know of the cash prizes so its a moot point, but perhaps macs are never kracked because there appear to be less of them. (many macs pretend they are unix and give false headers to requests to keep up the illusion, ftp http, finger, etc).
8> MacOS source not available traditionally, except within apple, similar to Microsoft source availability to its summer interns and such, source is rare to MacOS. This makes it hard to look for programming mistakes, but I feel the restricted source access is not the main reasons the MacOS has never been remotely broken into and exploited.
Sure a fool can install freeware and shareware server tools and unsecure 3rd party addon tools for e-commerce, but a mac (MacOS 9) running WebStar is the most secure web server possible and webstar offers many services as is.
One 3rd party tool created the only known exploit backdoor in mac history and that was back in 1995 and is not, nor was, a widely used tool. I do not even know its name.
Other than that event ages ago, no mac web server has ever been rooted,defaced,owned,scanned,exploited, etc.
I think its quite amusing that there are over 200 or 300 known vulenerabilities in RedHat over the years and not one MacOS 9.x or older remote exploit hack.
Not one. And that includes Webstar and other web servers on the Mac.
--- too bad the linux community is so stubborn that they refuse to understand that the Mac has always been the most secure OS.
BugTraq concurs.
I'm suprised no one has pointed out systrace yet. Granted, it's not for linux, only OpenBSD and NetBSD at this point, but it seems to be a very promising move in the ACL world. As one other poster commented, the most difficult challenge with any heavily ACL'ed environment is configuring the ACL's and making sure you didn't miss something. It's an extremely tedious process that requires a lot of reloads until it's done right.
Systrace eliminates much (but not all) of that initial trial period with a method of analyzing processes and watching what permissions for what resources they need and generating ACL's based on 'normal' use. This interactive mode ~greatly~ simplifies the otherwise length process of configuring the kind of security modules being discussed.
Also check out User Mode Linux. Its an open source project which does similar things. Rather than creating a whole new virtual machine, this allows you to run a linux kernel as a user space process, giving a whole virtual linux system inside it. And it does have a "jail" mode for increased security (separation between virtual server and host).
This has real potential for locked-down servers, kiosk systems, etc. It's a bit stringent for most desktops. But it's not too hard to use.
I used to run lids and grsecurity, but now I feel that the acl system in grsecurity is more powerful that that in lids.
Grsecurity's non-acl options are awesome. No setup, and almost all programs work as before (execept some programs that nedd stack execution, but that is a piece of cace to fix.)
BUT (and here comes my main point) the acl system (both in grsecurity and form my earlier experience from lids) needs more debugging. LIDS once released a version where you couldn't run (almost) any program because of the LD_LIBRARY flags, and grsecurity give me kernel panic every now and then. No problem on my system, it gives me and excuse for poking in the kernel source, but I would never use the acl on a production system.
in FreeBSD you have a "kernel security level" man securelevel
/dev/mem, and /dev/kmem may not be opened for writing; kernel modules (see kld(4)) may not be loaded or unloaded.
The kernel runs with four different levels of security. Any super-user process can raise the security level, but no process can lower it. The security levels are:
-1 Permanently insecure mode - always run the system in level 0 mode. This is the default initial value.
0 Insecure mode - immutable and append-only flags may be turned off. All devices may be read or written subject to their permissions.
1 Secure mode - the system immutable and system append-only flags may not be turned off; disks for mounted filesystems,
2 Highly secure mode - same as secure mode, plus disks may not be opened for writing (except by mount(2)) whether mounted or not. This level precludes tampering with filesystems by unmounting them, but also inhibits running newfs(8) while the system is multi-user. In addition, kernel time changes are restricted to less than or equal to one second. Attempts to change the time by more than this will log the message ``Time adjustment clamped to +1 second''.
3 Network secure mode - same as highly secure mode, plus IP packet filter rules (see ipfw(8) and ipfirewall(4)) cannot be changed and dummynet(4) configuration cannot be adjusted.
Common sense is not so common.
At least an authorizations/privilege security model instead of the anyone/root distinction is absolutely necessary.
The problem is, that many daemons (like Sendmail and such) override *all* security - of course, this is absolutely unnecessary.
For example, on Argus enhanced systems you run Sendmail with the pv_asn_port privilege instead of root privileges.
If someone manages to hack Sendmail, then the attacker can do nothing else than just open port 25, while on other OSs (even OpenBSD) the attacker gains root privileges.
Sendmail does not need root privileges to run, so why should we give Sendmail root privileges?
One key to more security is the 'principle of least privilege'. Modern Unix Operating Systems like Trusted Solaris show, that it is possible to implement fine-grained privilege control in Unix kernels.
Just securing a few dozens of applications (that's what the OpenBSD project calls OS security?) is not enough.
What if I need to run some other application?
An Operating System should be able to protect data even in the case, that an application gets hacked.
Our real problem is 'root' - it should never be used for any kind of server application (daemon), but only for system administration by an authorized user. There should not be any permanent processes running as root.
LIDS, the grsec patch, NSA's sample implementation of MAC and such things are steps into the right direction.
It does not raise the bar.. all intel stack exploits for LINUX can be trivially rewritten into PowerPC, and tutoraials have been written.
.exe extension can be executed!
1> There is no command line shell to allow redirection. No shell, no shell exploits or redirection of scripting.
2> Everyhing is 'root' at all times so programmers do not get lazy and fantacize about the existance of a more secure root to help protect them. The Webstar server, and other servers, as most mac programs, is written knowing that security is is important and that the code is running at root. Truthfully, PowerPC apps run at user-level, and Gary Davidian's birthdate needs to be passed in a register to gain true supervisor level, but no normal benefit is gained on a mac from running in the microkernel space or debugger-nub space.
3> Macintoshes do not suffer from stack exploits based on buffer overruns of C style strings. The mac uses Pascal style strings, instead of slow null-terminated strings in most all aspects of the entire operating system and in most users code. ANSI-C libraries are traditionally shunned. Pascal style strings are not only faster, they prevent the vast majority of buffer overrun problems.
4> Macintoshes do not EVER exucute code from file that are simple data files, no matter how the file is named or no matter how the file suffix is generated or set. Macintoshes use dual fork files, and text files and data files traditionally cannot easily become executables, and firthemore would typically need to have their 4-byte FILE-TYPE set to a value to even begin to allow a hackers file to be blessed for execution. Webstar and other tools do not typically allow any hacker or rougue tool to set file types by accident or on purpose. On a wintel system a text file saved with a
5> Source to mac os (pre os X) is not typically available outside apple corp. This is not a valid argument for security, (obscurity) but the appologists for the copious amount of linux redhat exploits use this as one reason for the many bugtraq exploits coverred.
6> The Mac OS weservers running Webstar do not automatically allow errantly saved files from executing out of the CGI bin merely because they are stored there.
7> The Mac OS has other good multi-homing multi-domain tools that run on it for robust free email (SIMS), DNS (QuickDNS Pro), FTP (Rumpus) and all have nice user interfaces to configure them and though these commercial tools may not be technically as secure as Webstar itself is, or the MacOS, I prefer them over running any open source tools on FreeBSD,NetBSD,OpenBSD,Linux, etc. Free is only free if you value your tech support at 0 dollars an hour sometimes. Plus, these other non Webstar related tools seem to have mostlty unblemished histories, unlike BIND.
8> People on the mac tend to use scripting languages based on Applescript rather than perl for os level dynamic work and protecting against some minor perl problems, or unix scripting (no command line on a mac, thankfully). I cannot attest to java as being swell, but the fact is many mac people tend to do dynamic content in straight C. Happlily Webstar includes a rich variety of trusted dynamic content assist tools.
9> Stack return address positioned in safer location than intel. Buffer exploits take advantage of loser programmers lack of string length checking and clobber the return address to run thier exploit code instead. The Mac places return address infornt of where the buffer would overrun. Much safer.
In fact in the entire securityfocus (bugtraq) database history there has never been a Mac exploited over the internet remotely.
A rare set of documentation tutorials and exercises on rewriting all buffer LINUX exploits from INTEL to PowerPC was published less than a year ago. The priceless hacker tutorials were by a linux fanatic : Christopher A Shepherd, 3036 Foxhill Circle #102, Apopka, FL 32703 and he wrote the tutorials in a context against BSD-Mach Mac OSX.
He was motivated by Phrack issue 49 (an intel article).