hardened-sources going forward

[ago]

https://blogs.gentoo.org/ago/2017/08/21 ... available/

[olger901]

What about the PaX patches? Will they remain available/free? Will they be added to the mainline of gentoo-sources?

[jonathan183]

I guess the masking of hardened-sources forces people to make a decision about what to do with the kernel.
Revert to gentoo-sources feels like a backwards step at the moment, staying on the stable 4.9 branch seems like a reasonable approach at the moment (using the patches ago posted about).
From the news item 2017-08-19 gentoo-sources and https://github.com/minipli/linux-unofficial_grsec look like the two obvious options to me.
What are others doing ...

[mx_]

Some guy porting the patches seems like a bad idea to me.

What about using CentOS or SLES kernel sources and create an ebuild for those?
https://software.opensuse.org/package/kernel-source
https://git.centos.org/summary/?r=rpms/kernel.git

[nokilli]

I guess the masking of hardened-sources forces people to make a decision about what to do with the kernel.

Best possible outcome is that Linus now looks at the problem with new eyes, takes the enormous satisfaction he's due in making the kernel the beautiful beast it is with respect to performance and stability, and turns his undivided attention to security.

All he really needs to do is just make the proclamation. Say that now is the time to move on security. I truly believe this; he does that, this gets done. So many people want to see this happen but he's, well, he's Linus... it's a hard road without his blessing. And security was already an enormously frustrating problem. Complicate it with politics? There shouldn't be politics here. There can't be. My computer? Then I get to decide what processes run and who gets to run them. Period.

I'm just this guy with a laptop but I've been giving it lots of thought and there's all this stuff that you can do to make your system more secure but really it comes down to process: recognize that what you're doing is shit, own that, and then content yourself with today's incremental improvement. And repeat. What else can we do?

What puzzles me is, how is this any different than the problem Linux faced with respect to devices? How many times were the way drivers work refactored in the kernel? Some company comes out with a dumb product but people want to use it but wow the way it works is really retarded and we have to rewrite everything just so this idiocy can have it's own module... when does that process ever end? Well, it's close to ending now. I believe that the kernel today is very close to a state where every kind of idiocy on the part of device manufacturers has been dealt with in one form or the other and I don't understand why security can't be treated in the same way. And yes I know about SoC's and that Linux is lagging here but like in every other aspect of life adversity here pays off over time. The process is working. We wouldn't be using Gentoo, using Linux, if it wasn't.

Maybe security is harder than that. But doesn't that then mean we should be embracing its solution all the more?

Failing that, the outlook is fairly terrible. Sitting from my very unprivileged position, it isn't entirely clear why security hasn't been given greater priority. And living in a post-Snowden world, I do see the priority my government has placed on compromising the security of the systems I run and I'm forced to wonder how far their pursuit of total control has taken them. Linus has hinted that he's had these kinds of conversations with the NSA-types. We want to believe that the outcome of these conversations have been favorable to our interests, but we can't know that for sure, because we're actually living in a world where the government can order you to do something and then also order you to not reveal that fact.

There is a very frightening possibility that Linus has a gun to his head and is doing exactly what you or I would do in that situation. Comply.

I remember back when SELinux was first introduced. Maybe this will be controversial in this place but at the time my impression was that OpenBSD was the preferred OS if your priority was security. So it was odd to see the NSA work to add mandatory access control to an OS that didn't then and doesn't now make security a priority.

The question I asked myself then was, how much of the NSA's budget was spent on working to protect the secrets of average ordinary Americans, and how much of it was spent to acquire the secrets of foreign nationals? If I were to guess that this ratio was 1%, would that really be all that controversial? So then what are the odds that SELinux was developed with our best interests first and foremost in mind? Was it funded out of the 1% of the NSA budget allocated to protect our (Americans) secrets or the 99% spent to get into them? Might this not have been a ploy to simply negate the momentum something like OpenBSD was enjoying at the time? And looking at the mindshare enjoyed by OpenBSD and Linux today, is it fair to say that if this was the mission then that the mission has succeeded?

[pjp]

[All he really needs to do is just make the proclamation. Say that now is the time to move on security. I truly believe this; he does that, this gets done. So many people want to see this happen but he's, well, he's Linus... it's a hard road without his blessing. And security was already an enormously frustrating problem.

Did not Linus have criticisms of Grsec code? Yet he let it in. While Linus' blessing may help, if a serious team got together to engineer a solution, past performance suggests Linux would allow it into the kernel.

Complicate it with politics? There shouldn't be politics here.

Unfortunately, politics appear to be part of the human condition. Maybe we'll eventually evolve out of that.

Well, it's close to ending now. I believe that the kernel today is very close to a state where every kind of idiocy on the part of device manufacturers has been dealt with in one form or the other and I don't understand why security can't be treated in the same way.

Bolting security on as an afterthought is probably the wrong security-minded approach. Coming up with a secure design from scratch is probably a better end game. Then make Linux a legacy hardware compatibility layer. Anytime you buy crap from a crappy vendor, call the vendor out on it when their crap results in security problems.

Maybe security is harder than that. But doesn't that then mean we should be embracing its solution all the more?

Failing that, the outlook is fairly terrible. Sitting from my very unprivileged position, it isn't entirely clear why security hasn't been given greater priority.

Security isn't something everyone knows how to do well. Linus readily admits not being a great SA or in the past having had difficulty installing Debian. So it is quite reasonable to believe he isn't a security expert, and it may be a Good Thing that he's not the champion for security in Linux.

And living in a post-Snowden world, I do see the priority my government has placed on compromising the security of the systems I run and I'm forced to wonder how far their pursuit of total control has taken them. Linus has hinted that he's had these kinds of conversations with the NSA-types. We want to believe that the outcome of these conversations have been favorable to our interests, but we can't know that for sure, because we're actually living in a world where the government can order you to do something and then also order you to not reveal that fact.

I don't for one second believe they have our interests on any list of priorities. Their list of priorities is the ability to bypass security in the pursuit of "National Security." I'll leave that as it is, otherwise it is likely to derail the thread, if it isn't already too late.

I remember back when SELinux was first introduced. Maybe this will be controversial in this place but at the time my impression was that OpenBSD was the preferred OS if your priority was security. So it was odd to see the NSA work to add mandatory access control to an OS that didn't then and doesn't now make security a priority.

I think it primarily says that the NSA wanted to use Linux but recognized that it was inappropriate for their requirements. I also think it is likely for Linux to me more secure with SELinux than without. That may include protections from the NSA as well (though I'm skeptical).

Might this not have been a ploy to simply negate the momentum something like OpenBSD was enjoying at the time? And looking at the mindshare enjoyed by OpenBSD and Linux today, is it fair to say that if this was the mission then that the mission has succeeded?

The solution will be for people to stop chasing after the newest, shiniest development toys.

Given the recent history you've touched on, using if not migrating to OpenBSD is on my To Do list.

[pjp]

Some guy porting the patches seems like a bad idea to me.

What about using CentOS or SLES kernel sources and create an ebuild for those?
https://software.opensuse.org/package/kernel-source
https://git.centos.org/summary/?r=rpms/kernel.git

What do they offer to make them a compelling choice?

[188562]

Some guy porting the patches seems like a bad idea to me.

What about using CentOS or SLES kernel sources and create an ebuild for those?
https://software.opensuse.org/package/kernel-source
https://git.centos.org/summary/?r=rpms/kernel.git

there was one project sys-kernel/geek-sources::init_6 with USE="aufs bfq bld branding cjktty ck deblob exfat fedora gentoo grsec ice lqx mageia openelec openvz openwrt optimize pax pf reiser4 rh rsbac rt suse uek uksm zen zfs" I quit working on it because no one was interested in it.

[mx_]

Some guy porting the patches seems like a bad idea to me.

What about using CentOS or SLES kernel sources and create an ebuild for those?
https://software.opensuse.org/package/kernel-source
https://git.centos.org/summary/?r=rpms/kernel.git

What do they offer to make them a compelling choice?

Both companies pay developer teams to create a stable kernel with bugfixes, security patches and backports. They are also involved in kernel developing.
The kernels are validated for commercial server hardware and include security features like apparmor and selinux. At least the SLES12 kernel supports live patching and they ship live patches.
There is likely much more, I did not lookup a documentation yet.
And they won't shut down their work of course :-)

[Ant P.]

All he really needs to do is just make the proclamation. Say that now is the time to move on security. I truly believe this; he does that, this gets done.

If all it took was Linus reciting some magic words, the nvidia driver would be dead by now.

[pjp]

Both companies pay developer teams to create a stable kernel with bugfixes, security patches and backports. They are also involved in kernel developing.
The kernels are validated for commercial server hardware and include security features like apparmor and selinux. At least the SLES12 kernel supports live patching and they ship live patches.
There is likely much more, I did not lookup a documentation yet.
And they won't shut down their work of course :-)

Ah, thanks. I thought maybe there was some specific security alternative.

[mx_]

Both companies pay developer teams to create a stable kernel with bugfixes, security patches and backports. They are also involved in kernel developing.
The kernels are validated for commercial server hardware and include security features like apparmor and selinux. At least the SLES12 kernel supports live patching and they ship live patches.
There is likely much more, I did not lookup a documentation yet.
And they won't shut down their work of course :-)

Ah, thanks. I thought maybe there was some specific security alternative.

That depends on your definition of "security".
I guess they don't apply the grsec patchset but they enable parts of PAX, include AppArmor and SELinux and have a business process of auditing and updating the code (https://en.opensuse.org/openSUSE:Security_Features). So yeah, they are a security alternative.
The gentoo-sources patchset for the longterm kernel looks mostly vanilla in comparison (https://dev.gentoo.org/~mpagano/genpatc ... 4.9-51.htm) thus offering less security related patches. So I like the "borrowed enterprise kernel on gentoo" approach better.

[pjp]

@mx_
(and of course anyone else who may be interested)

openSUSE kernel sources 4.4.87-18.29.1

[brendlefly62]

I've been basically off the grid for about six months; just returned from a 2000+ mile hiking project. I read the news today about sys-kernel/hardened-sources removal, oh boy:

... we will be masking the hardened-sources on the 27th of August and will proceed to remove them from the tree by the end of September... Our recommendation is that users should consider using instead sys-kernel/gentoo-sources

Will Gentoo continue to support its line of "hardened" profiles?

I have several servers running on the hardened/linux/amd64 profile with kernels built from hardened-sources configured with grsec. I also have a couple experimental desktops running on the hardened/linux/amd64 profile, with hardened-sources kernels not quite so hard as on servers (these have large package.use files to coordinate plasma, etc). How should I plan to evolve these systems?

1. stay on the hardened profile and just switch to the gentoo-sources kernel?
2. switch to the default/linux/amd64 line of profiles? maybe the new 17.0?
3. is there an overlay already sourcing the work from https://github.com/copperhead/linux-hardened or https://github.com/minipli/linux-unofficial_grsec? could I use that in lieu of hardened-sources?

[fedeliallalinea]

See here

[NeddySeagoon]

brendlefly62,

In the /17.0/ series of profiles the hardened profile is going away.

You won't be asked to switch profiles until gcc-6 is stable. At that time, Position Independent Executatbles (-fPIE) vill became the default for everyone.
Its another rebuild lots of stuff as it breaks all the static libs on the system.
However, if you are coming from the hardened profile, you can skip the rebuild as USE=hardened gives you that already.

My understanding is that userspace won't change for hardened users - everyone else will need to get into line but the kernel hardened patch set will go away.

There are several places trying to keep the hardened patch set alive, either by bumping it from kernel to kernel or trying to merge bits and pieces upstream.

I've been running the default/linux/amd64/17.0/no-multilib/ profile for several months on my main desktop. It mostly works but see the gcc-6.4 tracker bug.
If you can live with that try out the /17.0/ profile. If not, wait for portage to tell you about the new profiles.

Where I need hardened, I've updated gcc ... mostly, but still use the hardened kernel and hardened profile.
I need to test the profile change from 13.0/hardened to /17.0/ in a KVM before I do it for real on a system I need.

[pjp]

Merged previous 3 posts.

[Moonboots]

NeddySeagoon

Sorry a little dense today !

If the hardened profile is going away in series 17.0 profile. That will mean the "hardened" Flag will disappear and previously masked flags like JIT will return ?

[NeddySeagoon]

Moonboots,

Try the experiment for yourself. This is harmless as long as you do not install anynting whilu the /17.0/ profile is selected.

Run

Code: Select all

emerge --info

Select the the /17.0/ profile of your choice. Its not in eselect profile yet, so make the symline by hand.
Run

Code: Select all

emerge --info 

again and compare the two outputs.

For per package USE changes run

Code: Select all

emerge -pve @world

Switch back to your old profile before you forget.

[zorry]

Moonboots,

Try the experiment for yourself. This is harmless as long as you do not install anynting whilu the /17.0/ profile is selected.

Run

Code: Select all

emerge --info

Select the the /17.0/ profile of your choice. Its not in eselect profile yet, so make the symline by hand.
Run

Code: Select all

emerge --info 

again and compare the two outputs.

For per package USE changes run

Code: Select all

emerge -pve @world

Switch back to your old profile before you forget.

Hardened have a sub profile under the 17.0 profile and will be added to more of the sub profiles.

[depontius]

Hardened have a sub profile under the 17.0 profile and will be added to more of the sub profiles.

Is the "17.0" series going to subsume the "hardened" profile? Currently we have "/usr/portage/profiles/hardened/linux/amd64" beside "/usr/portage/profiles/default/linux/amd64/13.0" and its children. In the "17.0" series we also have "/usr/portage/profiles/default/linux/amd64/17.0/hardened".