re new grsec features from blog against Stackjacking

[konst]

First of all you and the PAX team do great work. Second I'm nowhere near the level of expertise to be able to understand all of it.

Moved thread_info off the kernel stack completely for both i386 and amd64 -- it's now located in the task struct, which is located in its own slab cache.

Any real world performance impacts of this? Shouldn't be any right?

Implemented PAX_RANDKSTACK for amd64 (without requiring MSR access, performance hit is the same as the i386 version since it calls the same function). This is applied per-syscall, making it essentially immune to infoleaks against the stack pointer itself, the same as on the i386 version.

Do you have any idea of the performance impact of enabling this? Seems extreme. Was this even necessary for real world apps?

Implemented additional protection in PAX_USERCOPY by identifying which slab caches required direct reads/writes from the userland accessor functions. Slab cache information is free within the current PAX_USERCOPY framework. We implemented a whitelist-based approach, and rewrote several areas of code to remove the need for direct reads/writes to certain structures so that the associated slab caches can be protected against direct reads/writes to/from userland. The technique allows for individual allocations within the whitelisted caches to be marked in the future, so that certain sensitive structures can be better protected. Of particular note is that task structs are protected under this mechanism.

Wasn't this implemented a while ago?

Implemented active response against kernel exploitation. Attacks by unprivileged users will result in a permanent ban of the user (all processes killed, no new processes allowed) until system reboot. Attacks by root (either by real uid-0 or as fallout from buggy post-exploitation cleanup) or while in interrupt context result in a system panic.

Do you or does anyone know the impact of this in a desktop system such as KDE or Gnome? Sounds like it would be a nightmare to enable this on a desktop cause apps are mostly not written with real security in mind but is it even necessary.

Extended automatic bruteforce deterrence to apply to suid/sgid binaries -- detected PaX terminations or crashes will result in a 15 minute user ban (the amount of time intended to help offset entropy reduction attacks).

Seems useful.

Improved MODHARDEN -- removed the fallback in netdev code to allow auto-loading any module when CAP_SYS_MODULE is present. The PaX Team came up with the beautiful idea, and I implemented a system by which we can control the entire asynchronous procedure of module auto-loading, along with correlating it with the original requester. Through this system, we can ensure (for instance) that mount -t can only cause filesystem modules to be loaded (verified through symbol inspection at load time). This system also has the side-effect of removing unnecessary reports for non-existent modules, as was the case in the previous system (since at request time we couldn't know whether the module existed or not). All these changes allow us to make stronger guarantees about the feature, regardless of any buggy privileged user code that performs certain actions on behalf of unprivileged users through dbus or the like.

This one seems useful.

[spender]

There shouldn't be any real hit from the thread_info move. Likewise, the impact of RANDKSTACK on amd64 is minimal (a handful of cycles). The purpose of it isn't for protecting userland applications, but to make certain vectors of kernel exploitation more difficult.

USERCOPY was implemented last year, but what we did last week was extend it. Before we were simply performing bounds checks on the copies, but not caring what was being copied to/from (for the most part). Now we have some degree of control over this for free.

There's no runtime impact of the bruteforce prevention/kernel exploitation response. There's no reason why the kernel exploitation response shouldn't be enabled for any system. It doesn't ban a user forever if they crash their own application; it only bans a user if they trigger a bad state (through an overflow or whatever else) in the *kernel*.

-Brad

[konst]

There's no runtime impact of the bruteforce prevention/kernel exploitation response. There's no reason why the kernel exploitation response shouldn't be enabled for any system. It doesn't ban a user forever if they crash their own application; it only bans a user if they trigger a bad state (through an overflow or whatever else) in the *kernel*.

-Brad

Thanks. Don't think I'll enable this unless someone has any info on how it impacts a totally hardened system. Don't exactly what some apps in KDE do but some now use qt JIT scripts and they trigger pax execution attempt in anonymous mapping. Pax just kills the app but if that option is enabled will it cause the user to be banned or if a root app triggers pax will it cause a panic?
yeah I know it's not a kernel exploit attempt by the app but ...

On a related note if I try to test my system with paxtest while enabling that option will it cause a kernel panic or ban a normal unprivileged user? (No I haven't tried it).

Correction: I meant the KERN_LOCKOUT not the bruteforcing option. The lockout seems extreme for KDE which has too many bugs.

[spender]

The "pax execution attempt in anonymous mappings" are PaX messages related to userland. These will *not* trigger the kernel exploitation response, as I mentioned.

You can run paxtest as any user to prove this

-Brad