
The status of Linux kernel hardening - cheiVia0
https://lwn.net/Articles/705262/
======
willvarfar
(I'm on the Mill team :) )

Its good to see classic ISAs moving away from memory protection 'rings'
towards arbitrary 'zones', even if retrofitting it e.g. SMEP/SMAP gives
horrendous APIs and a nightmare to keep checked and balanced! ;)

The Mill comes at this from the other direction, starting with 'zones' (termed
"turfs" in Mill jargon) and emulating 'rings' (if your kernel wants that) with
overlapping access rights between turfs.

On the Mill you can have lots of turfs that may or may not have disjoint
memory access, and you move between turfs synchronously with a special kind of
indirect function call termed a "portal". There are provisions for passing
across specific transient rights to memory in these calls, so you can pass a
pointer to a buffer and other aspects that facilitate the 'usercopy()'
mentioned in the article but with full hardware rather than software
protection.

We have tightened the portal/turf concept extensively since the Security talk
[http://millcomputing.com/docs/#security](http://millcomputing.com/docs/#security)
but it does give a gentle high-level intro to turfs and portals.

These days, we have facilities for passing buffers without exposing memory
pointers and other niceties to make it easy to write correct yet efficient
code. They can now all be made public but oh so little time, and I'm hoping to
get a white paper out about it by the end of _this_ month. Watch this space ;)

Happy to elaborate if anyone has Mill or general questions :)

PS an example of 'zoning' is [http://elfbac.org/](http://elfbac.org/) , which
is not getting enough attention. Its another way facilitate memory separation,
albeit by abusing the classic MMU and with inherent runtime cost. Elfbac is
userspace, but the hardware could be abused to protect kernels on classic CPUs
too. Well worth everyone reading :)

~~~
lmm
I was excited about the Mill when I first read about it 5 years ago. But at
this point is there any reason to believe I'll ever get to write code for one?
(Even via an emulator or something like that)

(I can't/won't watch videos, so will have missed anything that was only in
videos)

~~~
willvarfar
We are completely serious about building it. We are working hard towards that
goal. The team is 90% industry vets with very long careers designing and
making real chips in devices that really ship and are really still used in
their billions today, so we know what we're doing and just how long its going
to take. We're bootstrapped so we can't complete with chipzilla on timescales,
but we really desperately want to get Mill goodness out there as quick as
humanly possible :)

~~~
cheiVia0
Can we test it out on an FPGA?

~~~
rjsw
The official AARCH64 emulator is a Linux binary-only application. I would be
happy to play with a Mill equivalent.

------
contingencies
The reality is that the majority of systems out there use distribution vendor
supplied kernels. If you are in this camp, note that one of the best things
you can do for kernel security in production is run a custom kernel with all
of the features you don't need removed.

If you go this route, definitely consider grsec as well.

Reasonably tuning your kernel can also offer speed (eg. via more specific CPU
targeting), size and - critically for embedded environments - startup time
improvements.

~~~
yitchelle
> critically for embedded environments - startup time improvements.

This is so true. Back in the day when I was involve in embedded Linux
development, the quickest bootup time was about 40secs. This was booting a
v2.6 kernel in a minimum configuration on an ARM7 system over SPI NAND FLASH.
Hopefully, the bootup time is in the subseconds by now. Are we getting to
these speed yet?

~~~
_pmf_
> This is so true. Back in the day when I was involve in embedded Linux
> development, the quickest bootup time was about 40secs. This was booting a
> v2.6 kernel in a minimum configuration on an ARM7 system over SPI NAND
> FLASH.

The older NAND file systems were very slow. I've had a similar case where
repartitioning the huge NAND into a smaller partition and only using a small
partition reduced the boot time to 10 seconds without any other change. Modern
UBIFS systems apparently don't have this problem.

As for subsecond boot times: no chance with Linux.

~~~
rkeene2
I've booted Linux in sub-second times using User Mode Linux so there's nothing
actually preventing it other than the need to probe hardware in various slow
ways, which could be improved.

~~~
yitchelle
So this is going from connecting power to having a full system ready to go?

~~~
rkeene2
The question doesn't really make sense since there's no "power" involved --
the kernel neither has nor lacks power... but if I understand the nature of
the question, then the answer is "yes" \-- the system goes from not existing
to being at a bash prompt in under 0.3s on my laptop.

------
antocv
I urge everyone to use linux-grsec, and avoid the security hole that vanilla
kernel is.

This stuff has been there in grsecurity patchsets for more than 10 (ten) years
already.

~~~
omginternets
What's the easiest way to start?

~~~
majewsky
Some distributions carry kernel images with the patchset, e.g.
[https://wiki.archlinux.org/index.php/Grsecurity](https://wiki.archlinux.org/index.php/Grsecurity)

~~~
ckastner
Debian recently started providing such images as well:

[https://packages.debian.org/search?keywords=linux-image-
grse...](https://packages.debian.org/search?keywords=linux-image-grsec)

[https://wiki.debian.org/grsecurity](https://wiki.debian.org/grsecurity)

------
Animats
They mention the downside of address space randomization - it kills bug
repeatability. The effort to reproduce a crash is much higher. The result is
bugs closed with "cannot reproduce" comments from developers.

At least they're trying to reduce the attack surface. But the kernel is just
too big.

~~~
frederikvs
Couldn't they do something that's "repeatably random"? So that in case of a
bug, you can extract some information from your kernel on its current
randomisation, and then another kernel can use this information to repeat your
random layout.

E.g. use pseudorandom numbers, store the seed somewhere. In case of a bug,
extract that seed, pass it on to the dev, and he'll run his kernel with that
seed to reproduce.

~~~
DasIch
How do you prevent an attacker from getting the seed? This would just create a
possible attack vector that could be used to effectively disable address space
randomization.

~~~
frederikvs
e.g. only root can get access to the seed. Then the attacker would already
need to have root, so then you're in huge trouble anyways. And yes, it may be
weaker than a full-random solution. But a pseudorandom system that gets
accepted is more secure than a full-random system that doesn't get accepted.

------
w8rbt
I've been experimenting with Tomoyo Linux lately. To me, it's the simplest LSM
to reason about (although I have misconfigured it before). In the spirit of
Russell Coker's SELinux play machine, I have an initial Tomoyo test machine
that users may experiment with as root (uid 0). Feel free to ssh in and try it
out. If you find an issue, or bypass Tomoyo somehow, please don't damage
anything and let me know. Also, please no fork bombs. You don't need root to
do that:

    
    
        ssh -x -a root@montani.w8rbt.org
        Password = tomoyo1
    

Also, if you want to share this information with a friend, please use this
URL:

    
    
        http://w8rbt.org/montani/

------
totalZero
I feel like such a moron when I read stuff like this, because I don't know
what half the acronyms and technologies even are.

~~~
rasz_pl
Most(except ro/no exec) of the stuff mentioned are poor band-aid after the
fact just in case security by obscurity solutions :( Whats worse some of them
add baggage of kludges and cost extra processing, all in the name of slowing
down attacker (not stopping, slowing down). This is why Linus was mostly
skeptical if not opposing this (and grsec).

~~~
pjmlp
And all of them are band-aid for keeping to use monolith OSes written in C.

------
eugeneionesco
Don't waste your time with vanilla if you really care about security, just use
grsec.

~~~
viraptor
This would be great, but unless you've got a budget for support, you probably
shouldn't do it. When they say the free version is for testing, they mean it.
Probably on servers it's less likely, but on desktop it has a tendency to
crash xorg every few versions.

------
acobster
> Probabilistic protections can be defeated if the information leaks out, but
> they are still effective and worth doing.

What is the argument here? Is there something about this randomization that
distinguishes it from classic security through obscurity?

~~~
willvarfar
Exploit mitigation may be all that stops a vulnerability being successfully
exploited.

Here are some excellent slides on exploit mitigation in general:
[https://events.yandex.com/events/ruBSD/2013/talks/103/](https://events.yandex.com/events/ruBSD/2013/talks/103/)

Of the top of my head there are four approaches to stopping memory
vulnerabilities:

1) have no bugs, e.g. formal verification etc

2) use a memory-safe language

3) accept that there can be vulnerabilities, and use exploit mitigation to
harden it

4) capability-based addressing as a mitigation (it doesn't solve use-after-
free, for example; it relies on software to do that etc)

Of these, (3) is the one you can retrofit to existing C/C++ codebases... a
route you are usually forced to travel.

(There may still be other kinds of bugs, e.g. the obvious sql injections etc;
I am talking above about memory bugs specifically)

~~~
acobster
Yeah, makes sense. Thanks for the link.

------
tonyplee
I love to see Linux Kernel, distributions put more focus on easy program /
workflow that detect of insecure behaviors.

(Good old ZoneAlarm type GUI / workflow would be very nice.)

* Report and block if someone able to run any kind of privilege escalation exploit.

* Report and block if any non-white list apps attempt to make any network connections to internet and any external IP.

* Report and block if any non-white list apps, scripts try to run and execute any program.

Selinux seems to claim it can do most of these. But the barrier of entry to
setup and using it effectively is high (at lease for noob like me).

~~~
mixedCase
Please read on RBAC. If you don't want to learn SELinux you can use AppArmor
or grsecurity's RBAC system.

------
cyphar
Prepare for the lovely blog post from the grsecurity author who is going to
proclaim how he is so much smarter than everyone else, and that upstream Linux
doesn't know what they're doing.

/sigh

~~~
nwmcsween
grsec will sadly slowly become irrelevant, they could have worked with
mainline but instead acted like little spoiled children.

~~~
micaksica
I disagree with this statement. grsec has been a proving ground for a lot of
hardening technologies throughout the years, many of which are just starting
to make it upstream through the Linux kernel political process. As long as the
team that works on the grsecurity patchsets continues to innovate, it will not
become irrelevant; instead, it will continue to be a testbed for things
mainline will pick up and re-implement at their discretion.

~~~
nwmcsween
You seem to think grsec isn't in Linux due to the politics of submitting
patches, grsec hasn't submitted piecemeal patches and their attitude is to
derail conversations into name-calling. I recommend reading the comments in:
[http://lwn.net/Articles/663474/](http://lwn.net/Articles/663474/) or really
anything where grsec team interacts with people. You can be the most
intelligent human alive but if you cannot interact with people in a productive
way it doesn't matter.

