The security circus continues... (what else can it do?)

Kernel 6.11 has added yet more security garbage:

SLAB_BUCKETS

"Kernel heap attacks frequently depend on being able to create
specifically-sized allocations with user-controlled contents
that will be allocated into the same kmalloc bucket as a
target object. To avoid sharing these allocation buckets,
provide an explicitly separated set of buckets to be used for
user-controlled allocations. This may very slightly increase
memory fragmentation, though in practice it's only a handful
of extra pages since the bulk of user-controlled allocations
are relatively long-lived."

The rationale:

"many heap memory spraying/grooming attacks depend on using
userspace-controllable dynamically sized allocations to collide with
fixed size allocations that end up in same cache"

Yeah, sure.

Like who/what the fuck will ever attempt that on my personal
desktop workstation?

Just say "No." Keep your fucking security hallucinations off
of my fucking machine.

--
Systemd: solving all the problems that you never knew you had.

On 9/18/24 06:32, Lester Thorpe wrote:
> The security circus continues... (what else can it do?)
>
> Kernel 6.11 has added yet more security garbage:
>
> SLAB_BUCKETS
>
> "Kernel heap attacks frequently depend on being able to create
> specifically-sized allocations with user-controlled contents
> that will be allocated into the same kmalloc bucket as a
> target object. To avoid sharing these allocation buckets,
> provide an explicitly separated set of buckets to be used for
> user-controlled allocations. This may very slightly increase
> memory fragmentation, though in practice it's only a handful
> of extra pages since the bulk of user-controlled allocations
> are relatively long-lived."
>
> The rationale:
>
> "many heap memory spraying/grooming attacks depend on using
> userspace-controllable dynamically sized allocations to collide with
> fixed size allocations that end up in same cache"
>
> Yeah, sure.
>
> Like who/what the fuck will ever attempt that on my personal
> desktop workstation?
>
> Just say "No." Keep your fucking security hallucinations off
> of my fucking machine.

I now use only one distro with systemd, the other 5 don't even have it
as an option. It's all part of "embrace & extend", reminding me of
mozilla become an out of control behemoth on steroids starting to rattle
and crack at the seams (which is exactly how some virii attack their
target cells making them explode). What happens when systemd by virtue
of its size and reach starts dictating kernel development (I wanna hear
10-4 or roger-that)? Curtains for Linux, that's what! You'll interdict
more risks by using a usb wifi for PHYSICAL CONTROL instead of a
built-in and software controlled card than systemd will ever catch even
in the hypothetical case of it being an honest effort. I'll permit
myself to cite a revealing tidbit from 'Paul' in another thread the
other day:

"The most scary thing in the last two weeks, was discovering Poettering
works at Microsoft now."

On 18/09/2024 11:32, Lester Thorpe wrote:
> The security circus continues... (what else can it do?)
>
> Kernel 6.11 has added yet more security garbage:
>
> SLAB_BUCKETS
>
> "Kernel heap attacks frequently depend on being able to create
> specifically-sized allocations with user-controlled contents
> that will be allocated into the same kmalloc bucket as a
> target object. To avoid sharing these allocation buckets,
> provide an explicitly separated set of buckets to be used for
> user-controlled allocations. This may very slightly increase
> memory fragmentation, though in practice it's only a handful
> of extra pages since the bulk of user-controlled allocations
> are relatively long-lived."
>
> The rationale:
>
> "many heap memory spraying/grooming attacks depend on using
> userspace-controllable dynamically sized allocations to collide with
> fixed size allocations that end up in same cache"
>
> Yeah, sure.
>
> Like who/what the fuck will ever attempt that on my personal
> desktop workstation?
>
> Just say "No." Keep your fucking security hallucinations off
> of my fucking machine.
>
Well yes. More relevant to those running big internet hosted web servers
with many users having limited access that they might escalate.

But its symptomatic of modern Leftist thinking. Let's spend our time
solving unusual and interesting problems that we enjoy and can easily
solve rather than tackling the hard ones that require effort.

>
>

--
“when things get difficult you just have to lie”

― Jean Claud Jüncker

On Wed, 18 Sep 2024 14:51:10 +0100, The Natural Philosopher wrote:

>
> Well yes. More relevant to those running big internet hosted web servers
> with many users having limited access that they might escalate.
>

Of course. But regardless, every GNU/Linux distro will have this
enabled.

And by "every" I mean the Big Three, RedHat, Debian, and Arch,
from which every other distro is derived.

There is still plenty of choice in GNU/Linux land, but it is
not at all manifest.

--
Systemd: solving all the problems that you never knew you had.

On Wed, 18 Sep 2024, Lester Thorpe wrote:

> The security circus continues... (what else can it do?)
>
> Kernel 6.11 has added yet more security garbage:
>
> SLAB_BUCKETS
>
> "Kernel heap attacks frequently depend on being able to create
> specifically-sized allocations with user-controlled contents
> that will be allocated into the same kmalloc bucket as a
> target object. To avoid sharing these allocation buckets,
> provide an explicitly separated set of buckets to be used for
> user-controlled allocations. This may very slightly increase
> memory fragmentation, though in practice it's only a handful
> of extra pages since the bulk of user-controlled allocations
> are relatively long-lived."
>
> The rationale:
>
> "many heap memory spraying/grooming attacks depend on using
> userspace-controllable dynamically sized allocations to collide with
> fixed size allocations that end up in same cache"
>
> Yeah, sure.
>
> Like who/what the fuck will ever attempt that on my personal
> desktop workstation?
>
> Just say "No." Keep your fucking security hallucinations off
> of my fucking machine.
>

You do realize that the major use case for linux us not personal desktops
but servers?

And further, you are blessed! Due to linux nature, you can choose freely
which version of the kernel you want to run.

On Wed, 18 Sep 2024 21:50:18 +0200, D wrote:

>
> You do realize that the major use case for linux us not personal desktops
> but servers?
>

Of course I realize.

>
> And further, you are blessed! Due to linux nature, you can choose freely
> which version of the kernel you want to run.
>

Can I choose? As I indicated earlier the Big Three distros, RedHat,
Debian, and Arch, from which all other distro are derived, will
certainly include this latest security "feature." Thus, if I use
any distro at all I really cannot choose.

Fortunately, for myself, I use a customized Gentoo and I can eliminate
all that security cruft. But the average desktop user is stranded
and helpless.

--
Systemd: solving all the problems that you never knew you had.