Next official kernels

[Anlar]

http://ask.slashdot.org/article.pl?sid= ... 06&tid=185

As you might have noticed, they are thinking about what should be the new features in the next kernels. How about trying to get most of the Grsecurity integrated into standard kernels?

Seriously, running a server (or perhaps even a desktop) without all those updates seems like a suicide to me. The other OS (Windows) is doing it, the newest ones have a lot similar features and they most of the time work. BSDs are doing it too. Linux should do it. Now.

The only bad thing is that some software would get broken. Mostly some poorly written antiques like X but the options could be default off and it would force the X maintainers to start updating their stuff. Goes for the other software writers too.

In general it would do Linux a lot good. Being mostly immune to many kinds of attacks out of the box - no matter wether it is Debian, SuSe or RedHat or whatever. Security should be a standard and building insecure boxes to be pwned should be just illegal and dealt with harshly.

Bender, get to work with the present kernel maintainers about this one. I bet they will be quite interested in case they haven't been aware of this stuff already.

[spender]

They're not interested in grsecurity. They're interested in LSM. Grsecurity cannot work with LSM, and thus grsecurity will never be in the main kernel.

-Brad

[Anlar]

I am reading as we speak about LSM.. Uhh. Sounds.. Weird. What can LSM do is what the documentations are pretty hairy about.

[aldem]

Just an idea...

May be better alternative would be to convience major companies (like SuSe, RedHat) and major distro makers (Debian etc) to integrate grsecurity? Anyway they distribute their own kernels, with their own patches (all but Slackware), so...

Once it is in major distros - the [core] kernel team will have no chance to object.

...and before you say "No!" - have you tried?

[bluefoxicy]

*rolls his eyes* You people are weird.

Let me start by saying that this message isn't in the friendliest tone. I've heard things bouncing back and forth in the past few months that don't make me happy, and if I'm wrong on something, that's fine, go ahead and correct me on it, but bring some sort of proof to back up your claims. If you just say I'm stupid and don't understand something, but you don't give any technical reasoning for it, I'm going to assume you just don't get what I'm talking about, or just don't want to admit you're wrong.

First off, you need to separate out GRSECURITY into, say, GRKERNEL and GRACL. GRKERNEL could be all those lovely patches that randomize TCP ISNs and PIDs and that lock down chroot() jails; and GRACL could be the ACL system. Why? Because this is security, not a pissing contest. You don't need to tantrum about not getting your ACL system into the kernel, or not liking the way they're doing things. GET WHAT YOU CAN IN.

Second. LSM. I agree with Brad here. There IS a potential securiy hazzard of rootkits grabbing the exported security hooks and getting through kernel security, IF the ACL system is not set up properly AND if those security hooks have their symbols exported. This is not proven, but secadmins should not be forced to have these symbols exported. Easy solution.

I have a possible solution to this one. Spender, go talk to some of the other security projects, like Amon from RSBAC, and come up with a good set of hooks for LSM. ALSO. Suggest and possibly provide code to support that LSM modules can be staticly compiled into the kernel, so that the symbols do not have to be exported OUT of the kernel. If we are not going to load modules, then we should be able to avoid exporting all these nasty symbols and thus not have to worry about anyone rooting out the kernel unless they have /dev/[k]mem support, right?

Third. I don't believe in this technical impossibility you keep blathering about. Even if GRSEC doesn't use LSM hooks, LSM and GRSEC can work together, if they're aware of eachother. It's WORK, yes. It can be done, though. These are my views, and until I hear something more than "OMG LSM CAN NOT WORK WITH GRSECURITY HAHAAHAHAAHAHAHAHAHAHA LOLZ WTF ROFL!!!!!111111111113", something that intelligently supports these claims, I will keep these views. You don't have to like it, you don't have to argue with me about it, you don't have to correct me on it; but if you want to, bring something to back yourself up or I'm going to dismiss you as just another guy whining about it being cold at the dick-measuring contest.

-- john

[muff]

Ohh guys, let mr. Spengler do his work as he would like.
Its open-source, so when you want something
different or disegree with something do it another way
and modify to your point of view (see GPL).

I agree with mr. Spender, the way that he chose.

Look at FreeBSD, there is similar project named TrustedBSD to LSM,
but sec-developers of this project are not under force
of kernel maintainers as those in the Linux.

So leave mr. Spengler to do his great work.
And thing of yourselves.

[spender]

Have you read http://grsecurity.net/lsm.php?
Have you read the RSBAC link on that page?
You're underestimating the impact of the exported hook issue in LSM, since 95% of users will be using a kernel from their distribution, which will of course include LSM, and thus these symbols will be exported for all those kernels, where 99.9% of those users won't be using SELinux.

Your disagreement with what we've written is unfounded. Unless you'd like to tell me that you have more experience with the code base of grsecurity and LSM than I do, I don't see how you can claim to have a relevant opinion on this issue. This is no ego contest, it's not an issue of not wanting to do certain work. It's as simple as I stated it: grsecurity cannot work with LSM without a complete rewrite of the LSM hooks. The same is true for RSBAC and LSM. Also, you don't seem to understand the goals of the project. The goal is security, and using a multi-layered approach to accomplish that. Separating parts of the code so that some of it can get into the main kernel (and I think you are much too optimistic about what can get into the kernel) is not consistent with the goal. Since I am the only developer and have spent the last 3 years working on this code, I don't see what right you have to tell me what I should be doing. The beauty of open source is that if you don't like what I'm doing, you can go ahead and pursue your pipe dream of getting tiny features of my code into the main kernel. I have more important things that I could be working on that actually improve security instead of this. That's what people expect me to do, and that's what I'll continue to do.

-Brad

[bluefoxicy]

I've read both. I've also seen the SuckIt paper and know that a kernel without module loading support can be forced to load modules, so yes, I know there's a potential security hazzard with LSM. I understand how brain-damaged LSM is according to the papers I've read on it (I'd need a full logic outline to make a full assessment though). And I understand that the goal of a security project is security.

I also understand that there's no really good way to guard against malicious use of the LSM hooks once a malicious security module is loaded. This would go against the security goal of any security project.


So no. I don't understand anything.