# No more PaX, SELinux, etc?

## The_Great_Sephiroth

OK, so I just blew a week getting hardened+PaX+SEL on a new box, and then I saw the news article. After googling and reading a bit, am I to understand that we're about to lose EVERYTHING in security? I mean SEL, PaX, and GR? I finally take the initiative to give SELinux a shot at securing a box and in a month I lose it? What about Linux being GNU? How can a company charge for a modification to a free kernel? This doesn't make sense to me.

No, I won't run a testing kernel on a mission-critical box like the one I just built, so don't tell me we can still have those. What do we do for security now? Iptables and good permissions? What about a hardened kernel that doesn't use GRSecurity/PaX/SELinux? Will we have a stable hardened kernel with the hardened toolchain, or do we lose that too? What about other distros such as Debian? Does everybody in the Linux world now lose this security? What do we do?

----------

## vaxbrat

What news article are you talking about?

----------

## Hu

It is generally accepted that the GPLv2 does not automatically obligate a person in possession of modified sources to distribute those sources to any particular party, or to anyone at all.  That obligation is incurred as a condition of using the permissions granted by the GPLv2.  Thus, spender, or you, or anyone else, can make modifications to a kernel, avoid taking any actions which require those permissions, and thus avoid the obligation.  Since the GRsecurity project does not generally distribute compiled kernels, they are not taking any actions which require the permission for distributing derivative works.  They are thus free to share or not share their modifications as they see fit.

----------

## YumeWizard

 *vaxbrat wrote:*   

> What news article are you talking about?

 

This probably might not be what he read but it sounds like this is the issue he is referencing:

https://www.gentoo.org/support/news-items/2015-10-21-future-support-of-hardened-sources-kernel.html

----------

## The Doctor

 *The_Great_Sephiroth wrote:*   

> No, I won't run a testing kernel on a mission-critical box like the one I just built, so don't tell me we can still have those.

 Why not? Seriously, when was the last time an unstable kernel was actually unstable?

Also, need I point out that upstream says 4.6.4 and 4.5.7 are stable?

----------

## Ant P.

 *The_Great_Sephiroth wrote:*   

> No, I won't run a testing kernel on a mission-critical box like the one I just built, so don't tell me we can still have those. What do we do for security now?

 

If your livelihood hinges on this deliberate misunderstanding of what the word "testing" means in this well-defined and well-documented context, and you simply cannot live without what some third party (GRsec) has told you is good for you, it's time to pay their protection fees I guess.

SELinux isn't even anything to do with GRsec but there's not much point arguing that when there's so much else factually wrong with that post. You're off the deep end.

----------

## user

Waiting for "official" Grsecurity feature integration into vanilla kernel may comes to an happy end.

Beginning from Nov 2015 Kees Cook manage/maintain this long standing topic as Kernel Self Protection Project.

Cherry picking and low hanging fruit integration has started already. More details and concrete steps on mailing list kernel-hardening.

----------

## depontius

 *user wrote:*   

> Waiting for "official" Grsecurity feature integration into vanilla kernel may comes to an happy end.
> 
> Beginning from Nov 2015 Kees Cook manage/maintain this long standing topic as Kernel Self Protection Project.
> 
> Cherry picking and low hanging fruit integration has started already. More details and concrete steps on mailing list kernel-hardening.

 

So I presume as GRSecurity features make it in the base kernel, they will either be removed from the patch set, or we will be advised which base kernel features to turn off in favor of the patch set versions?  Somehow I'm guessing that we don't want two versions of some given feature turned on in both places, and I'm further presuming that they may never be fully equivalent, but almost certainly not yet.

----------

## The_Great_Sephiroth

OK, "testing" to me means it may not work as intended. Where do I get this? Binary distros I used for YEARS! Debian testing, for example. Most of the time it works. Sometimes it doesn't. I cannot afford to have a box down that earns money simply because I did an "aptitude update && aptitude full-upgrade". So please explain what "testing" means in the Gentoo world, because I probably do have the wrong idea. It's just that in the gaming, binary Linux, and well, everything else worlds, "testing" means it should work 90% of the time. If "testing" here means that it will work 100% of the time, I need to understand why it is called "testing".

The reason I mentioned PaX is because I found most of that configuration under the "GRSecurity" section in the kernel, leading me to believe that I need GRSecurity to have PaX. If I am wrong, why are these items sub-items of "GRSecurity"? I was mistaken about SELinux. I was tired and thought that SELinux was also under GRSecurity when I posted. I was incorrect. I can have SELinux without it, but the Gentoo SELinux Install Guide recommends that PaX be used alongside SELinux, probably adding to my confusion. My bad! Still, what about PaX?

So I guess I need to understand why "testing" is actually "stable" here. I cannot afford to have web-facing boxes have something not working that protects them, nor can I have a kernel that won't boot for whatever reason. This is why the term "testing" scares me. Care to enlighten me?

*EDIT*

Oh and the news announcement even said that we can expect things to break (or was it "not work"?) from time to time. This did not help things!

Found it!

 *Quote:*   

> Gentoo will continue to work closely with upstream to stay on top of any problems, but be prepared for the occasional "bad" kernel.

 

----------

## The Doctor

 *Quote:*   

> OK, "testing" to me means it may not work as intended. Where do I get this? Binary distros I used for YEARS! 

 Your mistake is assuming everyone plays with the same standards. Gentoo testing is about on par with most distro's stable desktop because we have higher standards.

 *Quote:*   

> It's just that in the gaming, binary Linux, and well, everything else worlds, "testing" means it should work 90% of the time. If "testing" here means that it will work 100% of the time, I need to understand why it is called "testing". 

 On Gentoo, nothing can be expected to work 100% of the time in all configurations. Hence half the threads on the forum. Every install is unique and therefore untested.

 *Quote:*   

> The reason I mentioned PaX is because I found most of that configuration under the "GRSecurity" section in the kernel, leading me to believe that I need GRSecurity to have PaX. If I am wrong, why are these items sub-items of "GRSecurity"? I was mistaken about SELinux. I was tired and thought that SELinux was also under GRSecurity when I posted. I was incorrect. I can have SELinux without it, but the Gentoo SELinux Install Guide recommends that PaX be used alongside SELinux, probably adding to my confusion. My bad! Still, what about PaX?

  Using security features you don't understand is often worse than not using any. SELinux is also developed by the NSA for whatever that is worth to you.  *Quote:*   

> I cannot afford to have web-facing boxes have something not working that protects them, nor can I have a kernel that won't boot for whatever reason.

 You realize that most distros intended to be web facing run neither SELinux nor GESecurity, right? The generic kernel is hardly without defenses. Although, 99% of your defense rests between the keyboard and the chair.

And why are you so panicked about a kernel not booting? Simply boot into the old one and fix it. Better yet, test the new kernel before deploying it. You are never going to be 100% sure that a new kernel will boot no matter what branch you use. The most likely cause in both cases is located between your keyboard and your chair.

As I pointed out before, upstream is quite comfortable calling kernels stable that are still located in the unstable branch for Gentoo and are available as hardened sources.

Maybe some homework would help? Take care as it hasn't been updated in a while.

----------

## Tony0945

To expand on what The Doctor has said, www.kernel.org presently shows latest stable kernel as 4.6.4, https://packages.gentoo.org/packages/sys-kernel/gentoo-sources shows latest unstable as 4.6.4. Kernel.org's long term stable is 4.4.15, still listed as unstable on Gentoo. Kernel.org's testing versions don't even appear in gentoo-sources.

I only recall having trouble with one kernel and it was pretty serious, under some combinations of options, ext4 was corrupting files. I think that's the sort of thing that you are concerned about. IIRC, that was a (Gentoo) stable kernel.   For a long time, I have unmasked gentoo-sources because it tracks upstream stable. That may not be the case with other packages, although in general Gentoo is pretty conservative compared to say Fedora.

I've considered moving over to unstable totally, but a test shows 571 packages to be rebuilt, so I'll wait until I change CPU and rebuild everything anyway.

Choices are:

1. Run stable and selectively unmask.

2. Run unstable and selectively mask.

3. Run stable unmasking only gentoo peculiar packages like portage, layman and eix plus selected upstream packages.

4. Run unstable masking only gentoo peculiar packages like portage, layman and eix plus selected upstream packages.

I'm leaning towards door number 4. I think the gentoo peculiar stuff is the real "testing" branch.

Comments gratefully solicited as I have a new motherboard and CPU on hand for my internal server (portage, distfiles, SAMBA, and webpages).

Not trying to hijack this thread. I just thought that general comments on 1-4 apply to the current subject.

----------

## The_Great_Sephiroth

See, I did not realize that Gentoo was that much more stable than binary distros. I also have not had any issues with regular Gentoo stable, except kernel 4 not recognizing or using my laptop soundcard, but that is a kernel or ALSA issue, not Gentoo. Either way I expected testing to be less than stable based on the entirety of the distros I have used in the past.

As for not understanding the security, this is true of PaX, but NOT of SELinux. I have a few web-facing systems using SELinux now and they work fine. I also know that the NSA helped with SELinux dating back to the 80's IIRC. Either way, I feel that the benefits outweigh the cons right now. Nothing personal is stored on this particular box. It will be used to host timeclock services for our clients, nothing more. If they want to see when somebody punched in or out badly enough, they'll do it.

----------

## The Doctor

Well, at least PAX, SElinux, GESecurity etc. is pointless for your setup anyway as they are intended to stop malicious binaries from executing. Since you really are not providing a vector for attack all you really need is to setup a good firewall, sanitize your database inputs, lock down or disable ssh and you should be good. It isn't like the general public has any reason to have access to your box so 99.9% of hackers are stopped right there.

At this point, I'd suggest you are absolutely the wrong person to be setting up this system. Since you say this is for a client then that implies they are paying you for expertise on security. As you clearly don't understand the security software and what threats they are designed to protect against you don't seem to be the right person for the job.

I say this is clear because you are confused about well documented projects. If you were an expert and had read the documents you would understand what they do, how to use them, and what they do not do. This thread demonstrates that is not the case.

I'm not trying to be a jerk. I'm just trying to point out that ignorance is not a substitute for knowledge and if you are being paid for knowledge you don't have it will come back to bite you.

 *Quote:*   

> As for not understanding the security, this is true of PaX, but NOT of SELinux. I have a few web-facing systems using SELinux now and they work fine.

 You seem to be implying that if you can get a system working with SELinux you understand it. This couldn't be farther from the truth. Getting it to run is easy. Understanding what it is doing, why it is doing it, and what it doesn't do is the important part.

PaX is a very simple concept that someone who is familiar with security or programming should understand very easily. It detects and stops stack smashing attacks and randomizes memory to prevent buffer overflow attacks. There is no need to run this type of protection on a system that will not be running user's programs. The same goes for SELinux and GESecurity in general. These programs are meant to stop a user from attacking the system they have access to, either legitimately or illegitimately. You shouldn't give people access to the system and you can limit the system's visibility taking care of both.

In your case, security means stopping unauthorized people from logging in in the first place. Simply set ssh to only accept public key authentication, and disable root login; and set iptables to drop all traffic not from wherever the people need to enter their time data, which also helps prevents fraudulent work hours and 99.9% of ssh attacks; and sanitize your database inputs because that is your most likely attack. I assume you will simply be using a simple web interface so no one will actually be logging on. Do you job right and there is nothing to attack.

EDIT: I'll just point out that security is a bit of a hobby for me, not something I'd consider myself an expert in.

----------

## The_Great_Sephiroth

Alright, I'll give you that I didn't understand PaX and may not be deploying it. However, why not use SELinux on a web-facing box as an additional layer of protection? I know iptables quite well and that IS my primary layer of protection. Lock out foreign countries with the xtables addon, allow SSH on a high port only from a specific address, etc, but why not add additional security?

As for the understanding, I come from a C++ background. I have always read and been taught not to worry about how a class/method works, just to understand how to use it and let it do its black-magic behind the scenes, especially since many of these things don't come with sources. Granted, the GNU world generally DOES come with sources, but I understand how to setup and use SELinux, so again, why not use it as additional security? It is the same reason that I lock down /tmp with "nosuid, nodev, and noexec" and then symlink /var/tmp to /tmp. I always believed that every little bit helps. Am I wrong?

----------

## The Doctor

No reason you can't. It is just overkill and comes with a performance cost plus the risk of adding a vulnerability to the system. Everything you run has the risk of unknown security exploits.

----------

## NeddySeagoon

The_Great_Sephiroth,

Security is like the layers of an onion.  You assess your threats and add the layers to combat those threats.

Defending against other threats is mostly harmless but can compromise performance and usability.

If you don't understand your threats, you are likely to defend against the wrong things.  That will give you a (false) warm fuzzy feeling.

----------

## The_Great_Sephiroth

That makes sense. Maybe SELinux is overkill on a server. Point taken. Still, I was just starting to read up on PaX and I really like what it offers for my laptop. Still a little confused about testing being bad on binary distros and great here though. Guess I don't have a choice if I ant to use it.

----------

## ct85711

 *Quote:*   

> Still a little confused about testing being bad on binary distros and great here though.

 

As The Doctor said, it lies down to the standard of expectations our devs has before they'll mark something as stable.  You can check a lot of the packages here, could very well be marked stable or even LTS upstream and still be marked as unstable here.  Quite often, a package won't be considered to be stable until it's been tested for a certain amount of time at the least.  Even then, they also look at what significant bugs are with the package and work to resolve most of them before they will stabilize it.  Then there is the part of all of the package's dependencies must already be marked stable too.  The last part is the big kicker, as unlike binary distros, the dependencies tends to be the largest holdup here (binary distros don't need to worry about build time dependencies, as it's already pre-compiled).

----------

## The Doctor

Also, if something in unstable turns out to be really buggy or introduce a serous security exploit it gets masked and removed fairly quickly. The unkeyworded packages and the 9999 ebuilds in testing overlays are the true testing branch in Gentoo.

As I said before, generally stable can be taken to mean ready for deployment on a server and unstable can be taken to mean suitable for a desktop. Overlays can all be classed as highly experimental, so you better double the normal number of backups at least.

In a case such as yours, I would simply use an unstable kernel with the remaining system stable. Mixing branches is generally not recommended, but the kernel is one of those things that really doesn't shake the boat.

----------

