Slashdot Mirror
Exec Shield for the Linux Kernel
DarkOx writes "There is a new patch from Ingo Molnar which can prevent overflow attacks. The scoop from KernelTrap is as follows: Ingo Molnar has announced a new kernel-based security feature for Linux/x86 called 'Exec Shield'. He describes the patch, which is against the 2.4.20-rc1 kernel, as: 'The exec-shield feature provides protection against stack, buffer or function pointer overflows, and against other types of exploits that rely on overwriting data structures and/or putting code into those structures. The patch also makes it harder to pass in and execute the so-called 'shell-code' of exploits. The patch works transparently, ie. no application recompilation is necessary.'"
Well, yes and no. Think about the analogy of this to driving. Cars today have a number of safety features, including seat belts, air-bags, anti-lock breaks, etc. Do we drive less safely because of them? More importantly, should we not include these devices in cars to increase driving safety?
I believe it was Chris Rock joking about this in one of his sketches. He claimed that airbags are NOT going to make someone drive safely. He said something like "What you need is a giant spike coming out of the steering wheel. That'll make someone drive safe!".
make world, not war
I'm trying to understand this fully, but I don't have all the background to do so.
:-)
From the announcement:
It is commonly known that x86 pagetables do not support the so-called executable bit in the pagetable entries - PROT_EXEC and PROT_READ are merged into a single 'read or execute' flag. This means that even if an application marks a certain memory area non-executable (by not providing the PROT_EXEC flag upon mapping it) under x86, that area is still executable, if the area is PROT_READ.
Is this limitation in the x86 processor MMU, or in the Linux kernel?
Is anyone working to fix this limitation? (E.g. AMD fixing it in 64-bit mode on the Opteron, or someone reworking the Linux kernel)
Furthermore, the x86 ELF ABI marks the process stack executable, which requires that the stack is marked executable even on CPUs that support an executable bit in the pagetables.
Does this statement imply that some x86 processors do the right thing with PROT_EXEC?
If Linus is willing to create a new ELF standard, could this problem be fixed? Would it be worth the pain of a new incompatible ELF standard? Are there any other problems that can only be fixed with a new version of ELF, so we can fix them together?
It would be sort of cool to get a new ELF standard, so that Linus can call the new kernel "3.0"!
steveha
lf(1): it's like ls(1) but sorts filenames by extension, tersely
The page says they are mapping all the code in the lower 16 MB of the address space. And they keep the first MB unmapped for NULL pointer protection.
;) They are emulating Windoze, you can't be serious about those 15 MB! That'll hardly contain GDI.DLL!
That leaves us with only 15 MB of space for code!
Are they really trying to say that they have not hit that limit yet? No program on earth has more than 15 MB code?! I can hardly believe that.
I was going to cite Emacs on this one, but Emacs is an interpreter, so the actual interpreter code might be small enough. Mhh. What about Mozilla?
Heck, what about WINE?!
Hope that helps!
Well, as long as MS keeps claiming IE, IIS etc. are part of the operating system and can not be separated, exploits against those parts should be filed against the OS. In Linux, when an application gets exploited, well you don't have to run that application, you don't even have to install it, it *is* separable from the OS! Especially as there are alternatives to (almost) everything...
Regards, Ulli
Simple things should be simple, complex things should be possible.
Umm... do you have some vague notion of what the kernel is? First of all, it isn't spelled with an "a". Secondly, ease of use of a kernel is a very messed up concept and I'm not even sure what it means. The kernel isn't easy or hard to use any more than winsock.dll is easy or hard to use. Very few programmers interact with the kernel except through libraries, so "easy of use" (whatever you mean by that) is much more important in the low-level libraris than the kernel. How does this affect marketability to individuals? Both POSIX and Win32 APIs are available on both systems. Are you referring to clean kernel interfaces, clean kernel implementation, availablility of the source for better understanding, or some other metric?
Kernel: That word... you keep using it. I do not think it means what you think it means.
I think you're thinking about UI. The GUI, the shell, the command line, the layout of the directories, etc. are all very very far removed from the kernel. In theory you could run explorer (the Win32 shell, not IE) on top of WINE, along with all of the Win32 programs and the user would have identical ease of use as Windows. 99.99% of users couldn't tell it wasn't the NT kernel and couldn't show evidence of it being Linux even if told (without watching the boot sequence). Asking about "ease of use" of a kernel is like asking about the top speed of your house. Neither question makes much sense unless you further define your strange thinking. You could guess that the person is asking how fast a house would be going when it hit the ground if dropped from 60,000 feet up (terminal velociy) just like you could assume a person is talking about how clean a kernel's APIs are. However, the usual sense of ease of use as realated to marketing to individuals is ease of use of the UI. I can only make educated guesses as to what strange thoughts are going through your head. For all I know, you filled hard drive platters up with both kernels and are attempting to use the platters to cut 440 stainless bar stock and are referring to the different metal cutting characteristics of kernel-filled HD platters. Please clarify exactly how you think the ease of use of the NT and Linux kerenls differ.
Copyright Violation:"theft, piracy"::Anti-Trust Violation:"thermonuclear price terrorism"<-Overly dramatic language.