Slashdot Mirror

I've had a look over their agreement here, and there is nothing to prevent redistribution of a patch under the terms and conditions of the GPLv2. It states that if it a patch is distributed outside of the terms of the GPLv2, then access to further patches in the future (not the patch provided) will be denied, on a works for hire basis.

I honestly don't think you've got all your ducks lined up here, and yes, I realise who I'm saying it to and how the hordes here will descend upon me.

... but rating them on their use of ASLR is worse than the problem:

https://forums.grsecurity.net/...

Find someone who's done some real security analysis, don't see if they bought the snake oil.

Sometimes I wonder if Linux should have functionality similar to AIX's trustchk.

Tripwire, SELinux, AppArmor...

grsecurity is more advanced then AppArmor, and even then SELinux. AppArmor does some simple RBAC SELinux does good RBAC GrSecurity does good RBAC, and provides wonderfull set uf kernel self-protection, memory protecion, randomization, logging, chroot jailing stuff (from PAX project). http://grsecurity.net/features.php

With friends we now develop a Hardened Debian offspin that includes grsecurity, for now just a tiny addon to Debian, but it does provide grsecurity kernel for debian pre-built and checksummed realibly for well over half year now. mempo.org project.

The parent poster is correct. Windows and Linux are totally different animals in regards to firewalls. There is only one firewall for Linux and it is built into the system. IPTables is how the firewall is configured. All other tools are just front-ends or wrappers for IPTables.

IPTables doesn't have support for application-based firewalling. You can do that kind of thing using something lilke the Grsecurity patch for the kernel, but it is not for beginners.

Grsecurity will let you create policies exactly like what you're talking about and then some. For example, it will allow you to create a policy limiting which files and folders a given program can access. To be specific, on my machine I have a policy that Firefox can only write data to it's own folders and to my Downloads directory, and can't execute/run any files inside those folders. That way, if somebody hits me with a drive-by download or something it simply won't work.

Forget SELinux, use http://grsecurity.net/.
See e.g. https://lwn.net/Articles/538221/

chroot was never intended to be a security mechanism, even though it can be misused for that purpose. There are a comically large number of ways of breaking out of a chroot, and preventing all the known methods requires patching the hell out of your kernel which will probably have the side effect of breaking various programs.

- first thing MS does is it kills supernodes and installs THOUSANDS of Linux servers running grsecurity http://grsecurity.net/news.php#Skype
- that means that ALL Skype traffic now passes through MS servers and can be easily wiretapped since MS holds all the keys and can easily perform a MITM attack

No, it means that SOME Skype traffic (i.e. text messages, but not voice calls) can be easily wiretapped.

tl;dr: Skype's a botnet and NSA paid MS to buy Skype

That's not borne out by your data. In fact, the Ars article referenced in your link states that supernodes play no role whatsoever in making calls.

I don't trust Microsoft at all; in fact, I think they can be relied on to do whatever they think is reasonable to get along with government (and by extension, law enforcement). But this particular issue - the establishment of grSecurity supernodes - doesn't get you an automatic MiTM capability.

it's remote exploits of one of the services that are installed, by default, to be accessible from the Internet.

Why worry about defaults?

If you're choosing Linux for security, you can already choose one of the security-enhanced distros like SELinux (if you trust the NSA) or Ubuntu Privacy Remix https://www.privacy-cd.org/, or LPS http://www.spi.dod.mil/lipose.htm, or Fortress Linux http://www.fortresslinux.org/ etc etc etc. Or just roll your own with your favorite distro and GRSec installed http://grsecurity.net/.

All of these are a (free) download away. It's not like it's difficult to secure Linux if you choose to.

That's why all this bullshit about Linux being as insecure as Windows, but less popular is just FUD. If Linux IS ever threatened the same way, the FOSS community is ready and has the tools to respond. Linux users won't have to wait for a vendor to reluctantly spend the money to ramp up a security team. They'll just benefit when it's needed.

You mean, the part of Windows that no one would ever reliably attribute to any instance of successful exploit unless it happened in a lab while running under a hardware debugger?

Well one way is to see the frequency with which the kernel binary is patched. A ton of malware is created after a OS patch is pushed (since most people run unpatched versions of windows anyway) . You can easily diff the patched binary and understand the code that was patched and create a working exploit.

What is it supposed to mean? Proprietary software vendors don't take responsibility for anything at all, least of all security of their software or any software that runs on their platform.

What I meant was if you do a total bug count of a fresh Windows install with a fresh Linux install, the linux install will have a higher bug count because of all the 3rd party crap that comes with it.

There is no "NT design". There was a kinda-microkernel architecture of the original NT that was quickly drowned in ad-hoc stuff bolted on top of it. No one knows how much of it remains there, or what it does now.

Where am I supposed to get any reliable information about Windows internals?

Read Inside Windows NT , or The NT Design Workbook

http://www.facultyresourcecenter.com/curriculum/BZ/pfv.aspx?ID=7401

If you want acess to the source code of windows you can easily get it if you're taking any computer science course in college/grad school or know anyone who does. But ofcource reading tons of implementation code to understand high level design would be a huge waste of time. I have it on my PC right now. I believe its a live snapshot of an XP era kernel from 2003.

Linux has Unix security and IPC at its core. It also has various forms of containers that properly isolate sets of processes (and happen to do everything virtualization does except running a different OS). That's actual security.

By design "UNIX Security" is nothing more than enforcing simplistic rwx permissions of files and mapped devices, etc. Process isolation is just the the MMU doing its job. Which is ironic because original UNIX was targeted for single processor with a swap file & no virtual memory. NTs object/token design is vastly superior to anything the unix based operating systems have come up with. Using basic NT functionality you can take any running process token and reduce its rights (for e.g. reading/writing to a specific folder or controlling any other I/O) dynamically.

Chrome uses this security model quite effectively for its sandboxing. Ofcource they had to re-do it for Linux because it doesn't have nay such security model by design. (unless the distros ship the bolted on crappy 'security' solutions)

Filesystem ACLs are a worthless add-on that I have never ever seen being used on anything Unix-like because they are a stupid idea.

Its only stupid on unix. On NT ACLs are a core design feature of the OS. It can be applied to anything - kernel objects, devices, even registry keys.

their access always fits into Unix user/group ID model.

No it does not. OK so I am a team lead for two teams and I want to give read access to spec documents to 5 members of team1 and 3 members of team2 and read-write access to only 2 persons one of each team. Under unix, the system administrator has to give me root password to create groups, etc which is retarded and a huge security hole.

Capabilities? Are you fucking kidding me?

Yes, they are a joke on Linux ! It has been pointed out more than once. Here is an example.

http://forums.grsecurity.net/viewtopic.php?f=7&t=2522

20 out of 35 capabilities offerd on linux provide no more security than

The grsecurity patchset lets you prevent the various ways of escaping chroot jails (of which there are a lot), amongst other things. But yeah, fundamentally chroot was never meant to provide security. IIRC it was implemented as a convenience feature for kernel development.

Is there some sort of exploit code I can run to check if my system is vulnerable? I tried to find some online, but I only came up with some code for SCO Unix and some code that is so horrendously long that I don't dare running it for fear it might do something I don't want to happen on my system.

The bug was found by Brad Spengler last month.

I thought we discussed this in July? Or is this a different exploit?

I think it's pretty clear that De Raadt and others have been discussing this vulnerability for quite sometime. On a list of affected systems, you can see it's been known on that site since August. Here's another fix discussed that involves setting PER_CLEAR_ON_SETID mask to MMAP_PAGE_ZERO and that's from July (unfortunately, as the Register article said, that might cause problems with applications). In fact I think Spengler has been talking about this for quite sometime as I believe you can find exploit code here and a video of it in use here against SELinux. If that's not the same exploit it sure seems to be very similar in nature.

SELinux has nothing on GRSecurity. http://www.grsecurity.net/

http://grsecurity.net/~spender/cheddar_bay.tgz

This ought to be crashing at the sk = tun->sk line, because the structure is smaller than a page, and page 0 is mapped no-access (I assume Linux does this; it's been standard practice in most operating systems for a couple of decades to protect against NULL-pointer dereferencing).

If you actually read the exploit code (see: http://grsecurity.net/~spender/cheddar_bay.tgz) the thing that really enables this exploit is one of two ways to map page zero. One of these seems to be a flaw with SELinux (either with the default settings and/or how the default config commonly ships) or using personality(2) to select a personality that explicitly allows this.

From the exploit for the personality case:

int main(void)
{
        int ret;
        struct stat fstat;
 
        ret = personality(PER_SVR4);
 
        if (ret == -1) {
                fprintf(stderr, "Unable to set personality!\n");
                return 0;
        }

Note you do need some setuid root program even with this (from my reading of the exploit code).

In the SELinux case "it just works" without needing the setuid program it seems.

Well, there *are* valid reasons for maintaining multiple kernels but security and "avoiding a monoculture" is not one of them.
Maintaining multiple kernels for the sole purpose of avoiding a monocolture would just be a royal waste of ressources...

Actually from a security point of view a kernel monoculture could even have advantages because all eyes would focus on the one kernel instead of spreading out over multiple targets. Just imagine having the OpenBSD guys focus their attention on linux instead of a separate kernel. Such an "uberkernel" would soon beat everything out there today in terms of security.

The windows monoculture is vulnerable because it is based on a sloppy, closed codebase, maintained by a single vendor that doesn't care about security.
The Linux kernel hardening patches and OpenBSD prove that security by design is possible in the OSS world. We could do better than windows if we wanted to - even and maybe especially in an open-source kernel monoculture.

....I thought that was the philosophy behind AppArmor (http://en.opensuse.org/Apparmor).

It's been deployed in SuSE products for years.

Apparmor seems to be a relatively sophisticated least-privilege system, i.e. the idea that if a BIND DNS server should never need to (for example) modify the routing table, then it also should not be able to modify the routing table. That way, if an attacker compromises said DNS server, he won't be able to do very much with it that isn't directly related to serving DNS requests (this is why I would personally refer to such a system as damage control, useful for containing/limiting an attacker who has already compromised something). The system discussed in the article is different in that it seems to be less concerned with what specific tasks a program should or should not be doing and more concerned with whether the code that is executed and the way that it is executed is what you would expect from the program's source. That way, if someone exploits i.e. a buffer overflow and inserts their own shellcode, it would deviate from the pattern that you would have expected from the exploited program and this deviation would be detected.

Both can be compared to systems like PaX (kernel) and SSP (userspace) which are intended to make sure that an attacker will fail to exploit an existing vulnerability, such as an unpatched buffer overflow, in the first place.

Not sure how this is better than what grsec and selinux does... They might be better suited to writing selinux modules than trying to reinvent the wheel here with what basically sounds like role based access control (RBAC) found in selinux

Because LSM is compiled and enabled in the kernel, its symbols are exported. Thus, every rootkit and backdoor writer will have every hook he ever wanted in the kernel. This will allow for a new generation of sophisticated backdoors and rootkits that will be nearly impossible to detect.

http://www.grsecurity.net/lsm.php

Modularity brings flexibility but also introduces new attack vectors. It is quite possible that one of these vectors undermines the whole effort to secure the system because an attacker only needs one succesfull exploit while the "defender" would need to avert and disable every possible attack route.

There are various issues with LSM but one concern is that its symbols are exported. Thus, every rootkit and backdoor writer will will be able to use these hooks.

* No attaching shared memory outside of chroot * No kill outside of chroot * No ptrace outside of chroot (architecture independent) * No capget outside of chroot * No setpgid outside of chroot * No getpgid outside of chroot * No getsid outside of chroot * No sending of signals by fcntl outside of chroot * No viewing of any process outside of chroot, even if /proc is mounted * No mounting or remounting * No pivot_root * No double chroot * No fchdir out of chroot * Enforced chdir("/") upon chroot * No (f)chmod +s * No mknod * No sysctl writes * No raising of scheduler priority * No connecting to abstract unix domain sockets outside of chroot * Removal of harmful privileges via capabilities * Exec logging within chroot

I don't claim to be a security guru, but it seems like many other administration tasks security is best applied in layers which butress one another and dovetail into a complete solution. While chroot is not in and of itself much of security enhancement it can be used to further enforce existing measures and removes some of the lower hanging fruit that less skilled crackers oft use to wrest control of an environment.

At any rate I'd be interested to see how many of your other "100 other ways" are easily protected against.

Breaking out of chroot is done via various pretty standard techniques, which can be blocked by patchsets like grsecurity. Not perfect, but properly applied you're likely to be protected from most 0day exploit scripts.

The obvious problem with this article is they mention using "Bastille" and forget to mention grsec. I don't really care about Bastille, but I do care about using grsec. Just because you turn off some services doesnt mean someone is not going to pop an xterm off your apache web server from some random cgi vulnerability... At least when someone compromises your web server in this way (which is probably how most linux web servers get compromised these days anyway), the attacker wont be able to do anything besides navigate the directory tree maybe. The attacker wont be able to view processes that are outside their own uid. The attacker wont be able to execute binaries outside of the standard bin directories (so custom scripts/binaries wont execute), and stack overflows do not allow execution of arbitrary code.. Its not a very fun environment to work in, most attackers will just look around and exit when confined to this type of environment...

This article makes no mention of grsecurity. Surely closing off unused services and patching vulnerabilities can certainly prevent a penetration, but what happens if a penetration is successful? grsecurity is the answer.

Whatever Redhat says, the fact remains that SELinux is an incredibly complex, and incredibly undocumented (or under-documented) piece of software. It took me two months to really understand how it worked and what exactly to configure when I needed to fine-tune access rights and permissions on our servers. That is a nightmare I wouldn't wish on anyone.

Redhat is not going to get much traction from this unless there is a very easy to use tool (preferably with GUI) to configure and customize SELinux, out of the box. The default tools on RHEL allow a few options during install time, but it is truly primitive.

There really doesn't need to be this huge love/hate relationship with SELinux, in fact why not just throw it out and use something far simpler and neater? There are several options out there. Off the top of my head I can think of GRSEC : http://www.grsecurity.net/

We've been using this on two of our server farms and it's been doing a superb job, and it is very very easy to customize compared to the SElinux nightmare.

mod_security and Hardened PHP can help with preventing future attacks that people don't yet know about.
Also, using something like GRSec, or SELinux can further restrict what people could do if they did end up with a shell on your webserver. Although whether it's worth the effort to set up for everyone is another question.

"It's my favorite feature within Windows Vista, it's called ASLR (Address Space [Layout] Randomization) .. a smart guy here came up with a solution, so we put it in Windows Vista.", Jim Allchin.

A smart guy at MS never did come up with the solution it's been around on other systems at least five years before Vista and it isn't totally secure. Software can never provide total security. Such protections belong in hardware, in the memory management unit.

"in my opinion, it is the most secure system that's available", Jim Allchin.

I think he means the most secure version of Windows.

"We have .. found .. buffer overflow, and those have been removed in Windows XP", Jim Allchin Feb 2002

So, isn't RISE (Randomized Instruction Set Emulation) similar in concept to PIC (Position Independent Code)?

If you want to secure computers via the Linux route then with Hardened Gentoo is a good way (Follow the Resources links in sections 6).

PaX is a hardened Linux kernel using ASLR (Address Space Layout Randomization) to support applications built as a PIE (Position Independent Executable) and to provide non-executable memory (NX).
PaX home.

PIE/SSP (Position Independent Executable)/(Stack Smashing Protector) (follow PaX link)
When an application is built as a PIE (Position Independent Executable) the code is able to be randomize on load up and NX bit set on certain parts of the application. At run time, when a buffer is created, SSP adds a secret random value called the 'canary' to the end of the buffer.

MAC (Mandatory Access Control) (follow Hardened Gentoo link)
Hardened Gentoo supports 3 access control solutions, SELinux , grsecurity , and RSBAC .

PIC Introduction and Internals.

Other references:
Hardened Gentoo Primer
SeLinux is supported by the NSA (National Security Agency) of the USA.

So, isn't RISE (Randomized Instruction Set Emulation) similar in concept to PIC (Position Independent Code)?

If you want to secure computers via the Linux route then with Hardened Gentoo is a good way (Follow the Resources links in sections 6).

PaX is a hardened Linux kernel using ASLR (Address Space Layout Randomization) to support applications built as a PIE (Position Independent Executable) and to provide non-executable memory (NX).
PaX home.

PIE/SSP (Position Independent Executable)/(Stack Smashing Protector) (follow PaX link)
When an application is built as a PIE (Position Independent Executable) the code is able to be randomize on load up and NX bit set on certain parts of the application. At run time, when a buffer is created, SSP adds a secret random value called the 'canary' to the end of the buffer.

MAC (Mandatory Access Control) (follow Hardened Gentoo link)
Hardened Gentoo supports 3 access control solutions, SELinux , grsecurity , and RSBAC .

PIC Introduction and Internals.

Other references:
Hardened Gentoo Primer
SeLinux is supported by the NSA (National Security Agency) of the USA.

It is because of this that other projects were allowed to flourish, namely the grsec jumbo patch. I think most people for the last several years have pretty much abandoned using (or even thinking of using) the openwall set of patches when other more feature-rich, updated patches exist and have existed for many years now.

Mac acting as a server -- with various remote services running and local access to users...[emphasis mine]

Microsoft has been attempting to get the scheme you're proposing working since 1997, and they're only trying to do it for a *subset* of the domain you're talking about. When they implemented it in the first place they did such a bad job that they created the worst storm of viruses and email worms the net had ever seen. Over a couple of years the number of active exploits of Microsoft's trust model turned viruses from a minor problem that you could easily avoid by a few simple habits to the biggest problem on the net... I'm seeing gigabytes of just rejected viruses and worms a month.

Nope, they try something different: They try to implement a zone model. On the first glance, this looks quite similar, but there is a big difference. Their zone model is insecure by default. When Internet Explorer looses track on a file downloaded from the net, this file becomes member of the local zone and is suddenly considered trustworthy. With a "secure by default" approach, a zone model could possibly work.

But it is quite interesting, that Active X is somewhat similar to the safe application model. In Active X components can be marked as safe for scripting. Such components can be embedded in IE and controlled by script code. Numerous exploits based on the fact, that unsafe components were marked as safe for scripting. Without some kind of online "trustworthy revocation list" the secure application idea will only work in a perfect world.

The IE zone model also shows, that there is indeed no border between applications and documents. One can easily create a HTML with active code. Although this page should be a document, it is indeed a program. When you save such a page, you have a ticking time bomb on your system. When you open the page from your local disc, the page is "executed" with your user privileges. It's not the application that is not trustworthy, it's indeed the document.

I don't want to have a full blown rigorous mandatory access control (MAC)security model on my Mac. I have some work to do and don't want to struggle with the system. GRSecurity and SELinux show how difficult these monsters are to configure, especially on a desktop system. But I want a lightweight, extensible mixture of a MAC and a zone model that warns me when I try to do something stupid. The system should interact with most of the existing tools, should be easy to understand and should let the user the last word. I think that extensible attributes with some simple rules built into the system might indeed fulfill the job. It's not a perfect tool, but it might help.

First of all, there's libsafe which is just a simple compile and install. Seeing as we don't know much about your specific problem, I'm not sure if it'll help.

Second to try is compiling your own custom kernel with the GrSecurity kernel patch. It has as part of it the PaX kernel patch which is very effective at protecting against overflows. You could even just install the PaX kernel patch itself, but I believe the version in GrSecurity is kept more up-to-date. You can compile it with protection turned off by default, but using the PaX tools turn on protection for just the binaries you wish to check.

Installing either (or both) of these could well help you, without the need to blow away your current install and start fresh.

First of all, there's libsafe which is just a simple compile and install. Seeing as we don't know much about your specific problem, I'm not sure if it'll help.

Second to try is compiling your own custom kernel with the GrSecurity kernel patch. It has as part of it the PaX kernel patch which is very effective at protecting against overflows. You could even just install the PaX kernel patch itself, but I believe the version in GrSecurity is kept more up-to-date. You can compile it with protection turned off by default, but using the PaX tools turn on protection for just the binaries you wish to check.

Installing either (or both) of these could well help you, without the need to blow away your current install and start fresh.

Why should anyone use this instead of grsecurity? I'm just curious, it's not meant to be a flamestarter. :)

You realise that because most distributions use modules, that a clever hacker (who's already got root) can easily install a root kit on your machine that cloaks itself, via good ol' insmod.

I'm a big supporter of Windows alternatives, but most are open to this type of attack too you know, it's not just Windows specific.

This is one reason I build all of my kernel images with the grsecurity patch and not using modules. I compile a static kernel only (no module support) and grsec patches the kernel to make it that much harder to insert running code into it (via /dev/mem, /dev/kmem, /dev/port)

I agree with your main point, my trust in the AV vendors has gone down a great deal. It's hard to detect, but that's what we're paying them for!

Tim

That is pretty much on target. SELinux only provides really only provides MAC (Mandatory Access Control). This is a big first piece but isn't enough to completely secure a system, there are still other considerations, such as system auditing, needed to have a fully trusted system.

For the most part SELinux provides binary compatibility for user space applications and ever since it was integrated into the 2.6 kernel provides binary compatibility with most modules... there are some modules that don't behave well with SELinux, some can be fixed with fine grained SELinux policies the rest need patches to their source to interact with the kernel correctly.

Applications don't really have anything to do with SELinux really, what SELinux (or really, what any MAC system does) is compartmentalize the system so that if any given application is compromised the break is limited to that one application and can not be capitalized on to compromise the system at large. SELinux and all other MAC systems rely on correctness of the policy configuration to provide system level security. Extra steps are still needed to protect each independent app though to make sure it is hardened against break-in. While it is important that a cracker is not able to take control of your box you still want to keep him from crashing your application server or web pages and such.

In addition to SELinux (NSA SELinux there are other MAC systems such as:
GrSecurity and RSBAC (RSBAC seems to be down though).

Other very interesting thing to look at are hardened tool chains (gcc with PIE, position independent execution and SSP, stack smashing protection) as well as PaX which is a kernel patch that provides extended security options such as ALSR (Address space layout randomization), non-executable memory. PaX provides some very strong kernel level features that harden all applications from attack. It does come at a slight cost though; some of the features have a minor performance hit, notably nx memory on x86 machines because they do not provide a true NX bit for pages, it has a fairly steep learning curve and some applications plain don't work with it... XOrg and Java VMs for example, because the way they are written they need executable pages for dynamic code generation. PaX security options can be set at a per file or per role (in a MAC system) level so it is still possible to run these apps, they just will not make use of the protection provided by PaX and will need to be tightened down in other ways. The really big gotcha with PaX is that elfloader doesn't support global offset tables or procedure linkage tables. These are required for ALSR in particular so to use PaX libraries need to be statically linked or loaded with dlopen... none of the current binary graphics card drivers for NVidia or ATI work with PaX so if you can't get 3D acceleration from DRI et al. you don't get 3D acceleration.

Why don't you install yourself a nice Kernel with grsecurity.

Using it's permissions system, you can allow root to login and do whatever you'd like, you but can set grsec so that only certain other groups/systems are able to view/run etc your perl code.

The permissions system is very configurable and it's a steep learning curve with not a real lot of documentation. But playing with it for a few days should get you all figured out.

Using grsec it's possible to allow root to login and really do zero damage, it's a great system. I don't think any Linux box should be allowed on the 'net without this patch! There are other systems (SeLinux) that offer the same sort of thing, so if GrSec isn't quite what you need be sure to look at the others.

Using a system like this means all those "they have root forget about it" isn't true anymore, you can configure it so root can do very little damage to the working system, but still have access to edit all those files the normal pleb user accounts can't.

Tim

How about fixing Xen to properly emulate the Intel x86 (post-Pentium-Pro) split-TLB architecture, so things like PaX will work in the VM? QEMU and Bochs also fail to do this, opting to use a single TLB instead. Until this is implemented, I'll be forced to continue using VMWare.

http://pax.grsecurity.net/
Protection Against eXecution.

and integrate it with something decent like http://www.rsbac.org/

Those are all good features to protect against poor coding, however, they are also features which are already available for the linux kernel. In fact it appears that all these features you've mentioned are part of PaX and are shared among linux and openBSD.

http://pax.grsecurity.net/

But perhaps of greater importance is the fact that none of this will protect you against poor coding which is susceptible to unexpected actions such as sql injection. An sql injection attack does not necessarily create a buffer overflow, but gets an application to execute a query in ways the programmer did not expect and thus uses the privileges of the database or application user to perform operations on the system which were not intended. And this was only one example of potential exploits an installed application may open up. There are others, some of them as simple as a poor password set by a user. You see, you must protect against more than just memory exploits.

selinux is very effective at protecting, not only against buffer overflows which may result in the execution of unexpected code, but other exploits:

"...Running an SELinux MAC kernel protects the system from malicious or flawed applications that can damage or destroy the system. SELinux defines the access and transition rights of every user, application, process, and file on the system. SELinux then governs the interactions of these subjects and objects using a security policy that specifies how strict or lenient a given Red Hat Enterprise Linux installation should be..."

http://www.redhat.com/docs/manuals/enterprise/RHEL -4-Manual/ref-guide/ch-selinux.html

So, again, I may be off base due to my lack of experience with bsd but I still believe that the BSDs are susceptible to attacks which an selinux implementation could protect against.

burnin

Indeed, something like http://pax.grsecurity.net/ is clearly useful, but breaks too many applications, is a kernel patch to the standard kernel that you have to apply yourself, so it's not so widely used. Neither SuSE nor RedHat supports it. OpenBSD does similar things, but they make sure that the ports and the system does not break. As a OpenBSD you don't have to do anything special, apart from installing OpenBSD, to take advantage of the security enhancements.

But such fine-grained controls are incredibly tedious

Hogwash. The grsecurity patches to the Linux kernel provide one approach to fine-grained access control that greatly eases the tedium of managing fine-grained rulesets. In short, grsecurity's approach is based on automatic learning -- let the system run in a permissive mode doing the things it's supposed to do, then generate a ruleset based on that activity. The system then runs with the generated permissions ruleset. The admin may need to tweak the ruleset for various reasons, but the tools provide a huge leg-up over any manual attempt to lock down a system that wasn't designed for it. And there's the rub... design.

With an OS that provides robust fine-grained access control, new software patterns and system tools emerge to manage the complexity. We didn't go from teletypes to OpenGL in one leap... For example, what if the only entity in the system that could even know the password database existed, much less access it, was the password service? Shadow passwords pale compared to that kind of isolation. What if the default permissions for an application effectively sandbox that app in a jail that makes Java in a chroot look like a toy? You'd then have to build additional infrastructure to allow the apps (and thus the user) do their work.

It's all quite possible, and folks are working on it now. This is the shift in mindset from allow-all by default to allow-nothing by default, and the work necessary to make that approach practical at the level of an OS. Take a look at http://www.coyotos.org/ and its predecessor http://www.eros-os.org/ for examples of current work on a OS (kernel and support infrastructure) designed for security (and performance) from base principles.

It's a daunting task, but damn well worth the effort IMO.

http://pax.grsecurity.net/

What it means is that a new copy of sshd is exec'ed for each connection after the master sshd fork()s to handle the connection. Previously, the forked sshd would just handle the whole session. It starts off as a literal copy of the address space of the parent and stays very similar throughout its life.

Now should there be some kind of vulnerability in sshd, an attacker can connect, get a new fork()ed copy of the master sshd and attempt to guess whatever they need to successfully exploit it. Should they guess wrong, their sshd will likely crash, but they can just connect, get another (identical) copy and try again.

Some systems (eg OpenBSD and PAX-based Linuxes like Adamantix) shuffle various things up (library offsets, stack location, ProPolice canaries, whatever) at exec() time. In the case of sshd, re-execing after the fork() means that instead of being able to linearly scan through the possible values needed to conduct the attack, the attacker has to guess the right ones for their current connection. Basically, instead of multiple shots at a stationary target, the attacker is now faced with an environment with lots of moving targets, all of which must be hit in order to conduct a successful attack. This should make it much harder to conduct the exploit.

For a look at those moving targets, see Theo de Raadt's Exploit Mitigation Techniques paper.

I'd love to be able to do more than that though.

Like being able to "noexec" on an entire directory, without having to break up the filesystem into separate partitions. 'chattr +n /var/tmp' or something like that.

Making an entire directory immutable would be great too. Eg 'chattr +i /bin' -- sadly thats not possible either.

grsecurity and lids are both capable of some of these things, but they are big scary kernel patches and each have a different approach to things, with their own configs and toolsets. And both can be pretty confusing.

Mono needs a bit of work to work with PaX, but it's possible. I mentioned the necessary changes to the Kaffe team; but they apply to any JIT.

The issue is that a JIT compiler like Mono generates code at runtime. Because it's not generated in realtime (it's compiled at the loading of an executable module, one time), it's feasible to dump the executable code to a file on disk and mmap() it in.

PaX won't allow code to be generated in memory unless the program has mprotect() restrictions off and uses mprotect() right. It's safer to rewrite the JIT compiler though, since you wind up with a stricter security policy that way.

Furthermore, Exec Shield's NX emulation is flawed, and the use of mprotect() in those ways would disable the protections on large parts of the binary. If anything happens in or above the stack, the whole stack is likely executable. This is in fact one reason I prefer PaX; a slight modification to Red Hat's kernel to print X instead of - in /proc/[pid]/maps for !PROT_EXEC memory that's actually executable prints out a good deal of areas that are executable but shouldn't be (rwx vs rwX).

Mono is flexible enough that C and C++ can be compiled to .NET. Microsoft supports this, as mentioned in earlier slashdot posts. It's really important to consider .NET and Mono as insecure, and to make sure they're adequately protected. If you're running all your programs in Mono and Mono has to disable PaX, then you lose the benefit of your GrSecurity-enhanced kernel. (same with ES).

Ok... when are you going to fix the nearly 2-year old Linux Security Module (LSM)'s security vulnerability for inserting malicious kernel modules (aka virus or trojans)?

So, I'm thinking that these "sky-is-falling" guys that have been ranting, raving and waving red flags over at GRSecurity, RSBAC are starting to have a solid valid point on the inherent weakness of the LSM model.

I truly hope this is not the beginning of open season for Linux-virus/trojans.

Ah? Hmmmmm? Welll?

Can you support your point? Your first link describes x86 segmentation, a hardware technique. Your second link is merely a link to a Google search. To my knowledge, Kaffe will spit x86 instructions into a JIT buffer on the heap. While I'm not familiar with the source code to Kaffe, I'm willing to bet that they do not use an old fashioned malloc() to allocate that memory on platforms with the NX bit (or they do another step to mark that memory as executable.) Can you correct me?