Live data from Hacker News

Passing the Baton

grsecurity.net

51–60 of 82 posts

Re: Passing the Baton

#51
post #16
post #14

Earlier quoted context omitted.

Torvalds claims [0] that he did not do enough arguing with upstream: > The apparent inability (and perhaps more importantly - total unwilling[n]ess) from the PaX team to be able to see what makes sense in a long-term general kernel and what does not, and split things up and try to push the sensible things up (and know which things are too ugly or too specialized to make sense), caused many PaX features to never be me…

PaX is developed independently from and usually shipped with grsec patches. AFAICT Spengler's not directly involved, and Torvald's comments don't reflect on them.

PaX patches are no longer independently distributed.

That stopped last year at the same time the -stable patches were made private.

Re: Passing the Baton

#52
post #49
post #16

Earlier quoted context omitted.

PaX is developed independently from and usually shipped with grsec patches. AFAICT Spengler's not directly involved, and Torvald's comments don't reflect on them.

Where does one obtain up to date PaX patches other than rolled into grsecurity? I looked and couldn't find it.

See my other post -- those patches were pulled back when the -stable tree was pulled, although you could previously get them separately, if you were daring.

Re: Passing the Baton

#53
post #16

Earlier quoted context omitted.

PaX is developed independently from and usually shipped with grsec patches. AFAICT Spengler's not directly involved, and Torvald's comments don't reflect on them.

Every post on lwn or mailing lists by "PaXTeam" is quite obviously spender with another handle.

paxteam is basically pipacs and spender is spender. You can read more about pipacs in phrack#66 [0].

[0] http://phrack.org/issues/66/2.html#article

Re: Passing the Baton

#54

I suspect this will just shift focus to the Kernel Self Protection Project[1]. It may end up being the best thing that could have happened for kernel security in the end. [1] https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Pr...

Could KSPP evolve to add missing features that are currently present in grsecurity? https://grsecurity.net/compare.php

If you're willing to wait a long time, then yes, KSPP, in years, might bring Linux kind-of on par with grsecurity today. If you mean in the short term, well...

What will likely happen is people will base new features on the last public 4.9.x patches, the same way prior KSPP patches have been, such as PAX_REFCOUNT or the read-only static variables, latent entropy, etc. (Frankly most of these are uninteresting compared to the powerful things like RAP, UDEREF, size overflow, etc, and the patches were in some cases neutered in other ways -- but whatever.)

However, grsecurity is more than that; if you watched the RSS feed, substantial amounts of effort went into also monitoring upstream kernels and carefully picking out security relevant commits and closing holes. The -stable grsecurity trees often had (literally) hundreds of included bugfixes that plugged things like minor infoleaks, 'benign' integer overflows, etc, when compared to the stable mainline kernels.

(In fact, there were few better resources for getting a peek at security-sensitive code "in the wild" being analyzed and fixed than looking at the grsecurity RSS feed, IMO. Huge amounts of it was very enlightening to understand what kind of security sensitive issues you can find..)

When a substantial amount of your infrastructure is about anti-memory corruption mitigations, taking care of stuff like infoleaks becomes more important. It is both the combination of all of grsecurity's features -- making most attacks substantially more difficult, or simply outright impossible in a lot of cases -- plus this kind of detailed attention -- not just stopping whole techniques, but also mitigating future possible attacks -- that put it very far ahead of the competition. It is not just a patch set, it is also very much a mind set, and a development model, behind the system.

In short, I don't agree this is the best thing that could happen for Linux Security or the KSPP. It's one of the worst, in fact. I think it means the KSPP will fall even further behind grsecurity as it will now develop all of its new protections privately (such as the whispered KERNSEAL), and they will be left to their own devices to develop new protections. (The current grsecurity authors have over a decade of experience in advanced anti-corruption techniques and kernel hardening, you're already starting the race late.) And even if they do rip the code out of the old kernels, and they do manage to keep it in tact without neutering or removing parts, it's not clear to me the kernels will still have the level of attention or mindset previously seen by the grsecurity team, which means it will overall still be worse off.

I knew this was coming after the -stable trees were pulled. It sucks.

Re: Passing the Baton

#55
post #18
post #14

Earlier quoted context omitted.

Torvalds claims [0] that he did not do enough arguing with upstream: > The apparent inability (and perhaps more importantly - total unwilling[n]ess) from the PaX team to be able to see what makes sense in a long-term general kernel and what does not, and split things up and try to push the sensible things up (and know which things are too ugly or too specialized to make sense), caused many PaX features to never be me…

What's this, you suggest? Linus Torvalds and the kernel project in general not getting along with a serious security project? Why, I never! Torvalds does great work. Spengler does great work. The kernel team does great work. The PaX team does great work. Torvalds is not always the easiest person to get along with. Spengler is not always the easiest person to get along with. Life is sometimes complicated. None of this…

Thing is that the day Torvalds push a kernel that break some big name production environment is the day either the update gets ignored (effectively forking the kernel), or the big name goes looking for alternative platforms.

You see this back and forth happening over at Windows as well where continued backwards compatibility is weighed against future security.

Just look at the more restricted capabilities of anything WUP vs Win32 (never mind Win16).

Re: Passing the Baton

#56
post #42
post #32

Earlier quoted context omitted.

Incorrect, Kees Cook, who more or less founded the KSP project (kernel self protection) has been working on this for several years to enhance the security of ChromeOS while working for google. He started some of it when he was working for Canonical and has been doing this non-stop. The problem is that getting things into small individually testable components is literally anathema to the Pax/grsecurity model. They ha…

> The problem is that getting things into small individually testable components > is literally anathema to the Pax/grsecurity model. no, you're wrong. how do you think we developed our code? did all the 8+ MB worth of it pop out of our head all at once? or more realistically, did we develop the features piece by piece, not unlike how upstream linux is developed? > They have very specific "chunks" of functionality wh…

Well I recall a somewhat recent case where you mentioned how there was one of features (I want to say it was the KASLR) that depended on another feature which still isn't in. You (spender in specific) mentioned on LWN how basically the feature was no good without the other 1/2 and the two changes were both somewhat invasive (in the Linux kernel context what Linus would consider invasive). I'm not saying you're wrong in any way or that you developed all 8+MB of code in 1 chunk. I'm saying you design your components to go together and depend on eachother, not to be split up individually and added sort of kind of willing/nilly.

Did I get that wrong? From reading Brad on LWN for literally years wank about Linux security (he's absolutely not wrong to complain), this was my take. Or it could be summarized as (this is satire):

    PaxTeam: This is our code, it is open source, it is more secure than the dumpsterfire that is upstream, take it if you want it.
    
    Linux Upstream: That is nice, now break it into 1000 individual patches each independently git bisect-able. Also, can you change the interfaces of these design flaws in Linux and THEN entirely re-do your well tested patch to match the way we do code upstream and match the interfaces we would *like* Linux to have that we're going to expect you to code for us.
    
    PaxTeam: No, we want to do more interesting things like build more secure patches for Linux and look at pictures of cats on the internet, as it was designed to be used for.
    
    Linux Upstream: ...

Re: Passing the Baton

#57
post #32

Earlier quoted context omitted.

Incorrect, Kees Cook, who more or less founded the KSP project (kernel self protection) has been working on this for several years to enhance the security of ChromeOS while working for google. He started some of it when he was working for Canonical and has been doing this non-stop. The problem is that getting things into small individually testable components is literally anathema to the Pax/grsecurity model. They ha…

He could have been working on it for 26 years and still failed to get it in, which would only mean that he sucks at it. Other people have gotten large changes into the kernel before, but they require interfacing with the kernel devs and agreeing to certain changes first. Nobody's going to accept a patch just because Google wants it for one of its products. And Google isn't going to change its product patches just so…

You realize he is a core kernel dev, right? He's splitting into pieces one at a time. When a part of Linux sucks and your patch changes it, upstream has you change the part that sucks and then adapt your patch to it. Makes things often take longer than necessary for new contributors.

To give you an idea of Kees's contributions:

    ~/git/linux (master)$ git remote -v
    origin	git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git (fetch)
    origin	git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git (push)
    ~/git/linux (master)$ git pull
    Already up-to-date.
    ~/git/linux (master)$ git log --author="Kees Cook" --pretty=oneline | wc -l
    701
Basically, he is getting as much of grsec as is feasibly upstreamable upstream as he's able to. Due to upstream Linux policies, the end results often turns out very different than the original grsec patches they were extracted from. Perhaps that is a better way of putting things?

Re: Passing the Baton

#58
post #54

Earlier quoted context omitted.

Could KSPP evolve to add missing features that are currently present in grsecurity? https://grsecurity.net/compare.php

If you're willing to wait a long time , then yes, KSPP, in years, might bring Linux kind-of on par with grsecurity today. If you mean in the short term, well... What will likely happen is people will base new features on the last public 4.9.x patches, the same way prior KSPP patches have been, such as PAX_REFCOUNT or the read-only static variables, latent entropy, etc. (Frankly most of these are uninteresting compare…

> substantial amounts of effort went into also monitoring upstream kernels and carefully picking out security relevant commits and closing holes

This would better be a project done by these same people, in the upstream, to ensure that the -stable branches of regular kernel packages receive security updates, no?

Re: Passing the Baton

#59
post #6

Earlier quoted context omitted.

Of course you can. https://01.org/linuxgraphics/gfx-docs/drm/admin-guide/tainte... Edit: --- Good point about the distinction between adding modules modifying existing source. It is an interesting question, actually and I haven't been able to find an authoritative answer on the subject. A patch is a description of changes that would be made to a work, if they were made. Does it trigger the licence before it is applie…

That's not the same thing at all. The 'P' taint flag exists because upstream kernel maintainers aren't interested in dealing with bug reports where the bug may have been caused by proprietary code loaded by end users, which often can't be examined or copied even for the purpose of discussing the bug. Total waste of time, so the flag makes those cases obvious to anyone reading the bug report. The user can be told upfr…

> You don't even have to accept the terms of the GPL just to run the program.

Why do so many pieces of FOSS software—especially in their Windows or macOS distributions—have clickwrap that makes me accept the GPL to install them? Are they just misinformed?

Re: Passing the Baton

#60
the FAQ mentions "KERNSEAL, STRUCTGUARD" -- what are these? I tried searching on google but didn't find anything about either.
Post reply on HN