Linux 4.16 Is Tightening Up Access To /dev/mem By Default

[pal666]

there are many ways that root can read memory.

there are no ways for root to read arbitrary memory without kernel help

[Guest]

What ever happened to "security people are f$cking morons" (1*), "don't break users" (2*), and "I don't trust security people to do sane things"(3*)?

1) Original quote is [Context] ... "Those security people are fucking morons".

As long as you see your hardening efforts primarily as a "let me kill
the machine/process on bad behavior", I will stop taking those shit patches.

I'm deadly serious about this.

Some security people have scoffed at me when I say that security problems are primarily "just bugs".

Those security people are f*cking morons.

2) First of all, quote is "we don't break userspace". Secondly only people with _clean_ kernel config will get this AND almost nobody uses /dev/mem for accesing kernel stuff anymore, except for memory forensics/hacks based that read and parse kernel memory from userspace and long time obsolete software. Also, bunch of distros have done this already and nobody even noticed or made any kind of significant fuzz about it. This also potentially prevents non-security related bugs and the main justification for even adding it at the time was that it was sometimes useful to read upper 1MB of BIOS reserved physical memory on X86. Distros kernels have literally defaulted to "Y" since 2010 or something.
3) Same context as 1)

People who take issue specific insults from rants, misquote them to use them to support their own narrative context in ad hominem attacks are fucking morons. And I don't mean it in general, just for you.

Obvious trolls are obvious, I suppose that Insidejob guy is gonna soon join my ignore list as well.

[OneTimeShot]

“there are no ways for root to read arbitrary memory without kernel help”

True. The Kernel will help in many ways...

insmod is an obvious one.

Hexdump /dev/sda will show some stuff if you fill up ram or hibernate...

cp mykernel /boot/linuz-xxx and reboot.

Plus us lots of other ways I cannot think of at the moment.

[starshipeleven]

What ever happened to "security people are f$cking morons", "don't break users", and "I don't trust security people to do sane things"?

Taken out of context much?

The rant they were excerpted from are for either that time he had to give root password to add a printer (or add a wifi network), or the other time when he flamed the whole software security industry because it works waay too similarly to journalism and is not actually helping making things really secure.

[starshipeleven]

“there are no ways for root to read arbitrary memory without kernel help”

True. The Kernel will help in many ways...

insmod is an obvious one.

Hexdump /dev/sda will show some stuff if you fill up ram or hibernate...

cp mykernel /boot/linuz-xxx and reboot.

Plus us lots of other ways I cannot think of at the moment.

You are looking at this from the wrong angle. A Linux distro gives the administrator full ability to do all he wants, one way or another. This isn't Windows or MacOS (or Android).

What this feature does is blocking unauthorized access, so malware, and low-skill hacking attempts.

insmod can't be used to insert unsigned modules (to relax security for example) when the kernel is booted in Secure Boot mode in UEFI, nor you can just change the kernel without also signing it again if you have Secure Boot enabled.

swap can be encrypted, just like any other partition. If you use a swapfile in an encrypted root partition the end result is also the same.

[OneTimeShot]

“You are looking at this from the wrong angle”

not 100% convinced by that. Root can do anything. SELinux extends that to “root and ability to load different SELinux Policy”. UEFI extends to “can pay Microsoft for a signing certificate” or “can find an existing signed module with a vulnerability”.

I’m not saying that this a bad idea, but pretending that you are stopping the attack is pointless. Root access is usually one small step away from owning kernel space.

[schmidtbag]

I don't really see the problem with this. I feel like the pros heavily outweigh the cons, especially since you can override this if you really need it. Remember, this is memory access - this is pretty much the last thing you want freely accessible by userland applications.

[starshipeleven]

“You are looking at this from the wrong angle”

not 100% convinced by that. Root can do anything. SELinux extends that to “root and ability to load different SELinux Policy”. UEFI extends to “can pay Microsoft for a signing certificate” or “can find an existing signed module with a vulnerability”.

I’m not saying that this a bad idea, but pretending that you are stopping the attack is pointless. Root access is usually one small step away from owning kernel space.

No defence is 100% impregnable. All defences either slow down the attack or raise the difficulty.

In this case, instead of just using some shell script escalating privileges and then reading from /dev/mem you suddenly need to be able to do a privilege escalation from an application that by default does not have access to 100% stuff could exploit because of SELinux locking down all unnecessary access for it, then find a UEFI exploit that allows you to bypass somehow SecureBoot (because people using SecureBoot to secure their linux system WILL purge the other keys so the Windows one won't work anymore), and then you can either load a compromised kernel or kernel module so you have access.

I'm not saying it's impossible, UEFI is a piece of shit, so some way can be found.

But that's still more complex.

Again assuming all the things I mentioned are employed and configured properly. SELinux usually isn't terribly hardcore on Linux distros. It's used hardcore on Android.

[OneTimeShot]

“instead of just using some shell script escalating privileges and then reading from /dev/mem”

agreed, but again, if I have root access with a script I’ll be too busy messing with /etc/passwd and ssh stuff to worry about /dev/mem. And an attacker with the skills to look into /dev/mem will certainly not be slowed down by any of these obfuscations...

so - yeah, I don’t disagree with /dev/mem not being mounted in a production install. But... Meh... don’t run bad stuff as root, I guess...

[starshipeleven]

agreed, but again, if I have root access with a script I’ll be too busy messing with /etc/passwd and ssh stuff to worry about /dev/mem.

Not even root cannot patch running applications, nor kernel/drivers, which is what /dev/mem allows. They are disabling access to it to protect kernel/drivers/applications from (potential) runtime patching done by rootkits.

It's a bit different (far more powerful and subtle) than just having ssh access and console root, you can extract info or inject stuff into programs with that. Root can't do that unless the kernel allows him to.

And an attacker with the skills to look into /dev/mem will certainly not be slowed down by any of these obfuscations...

Sure, if someone has studied a single program ram footprint to inject stuff in it on runtime then it instantly becomes omniscient and can hack UEFI and the Kernel and everything else.



I'm not saying it can't be done, just that it becomes much harder.