On 4/4/14, intrigeri <intrigeri@???> wrote:
> Hi,
>
> Jacob Appelbaum wrote (04 Apr 2014 12:52:59 GMT) :
>> I'd be interested in trying to get a grsec patched kernel
>
> This is awesome news for Debian and Tails!
I've had some discussions with Spender, the main grsec person and he
is also keen to make this happen.
>
>> into 1.0 or 1.1
>
> 1.0 will be a point-release, so introducing a large kernel patchset is
> clearly not an option. 1.1 might work, but not sure Debian will be
> fast enough, even if you are. Anyway, you know what? We'll merge it
> once it's ready :)
>
Awesome to hear!
>> - how do we suppose we could make this happen?
>
> You'll have to find a "working code and rough consensus" solution for
> https://bugs.debian.org/605090. The maintainability concerns if this
> new kernel was to be released in Debian stable are quite challenging.
>
I'll look at that bug and give it a think.
> Perhaps a "let's do that only in sid to start with" approach would
> help:
>
> 1. this new kernel's maintainers get used to the job, and prove
> they can sustain the workload and act in a timely manner
> whenever other parts of Debian are blocking on them
Good news - Spender wants to make Debian grsec a reality. He is the
upstream patch creator and author of grsec. There is no better person
to involve and he has been making patches against the linux kernel for
years without fail.
> 2. the Linux maintainers in Debian, and the stable release
> manager, get an idea of how much critical paths are extended in
> practice... and get confidence in the grsec team;
That is upstream isn't it? That is - the kernel team in Debian has
been working with upstream to ensure the two kernel trees are in sync,
right?
> 3. users who want, or need, a hardened kernel -- of course! :)
>
>> I discussed this with another Debian developer and they felt that
>> a kernel flavor is the way to go.
>
> After quickly skimming over #605090 again, I doubt this will be
> acceptable without a strong team, that has proven they are able to be
> fast enough not to delay non-grsec kernel updates (too much).
>
I think we should ask Spender to join such a team. Also, I guess I'd
ask you too. :)
>> How might we ship grsec + pax to end users? What would be useful here
>> for me to do? I'm happy to rebuild the kernel with the specific
>> patches but I'm sure that is far from enough... :)
>
> I'm afraid I don't get what you mean here.
>
I was thinking that we should come up with a todo list - for example -
to ship an experimental grsec kernel in the next version of tails (to
be selected by beta testers).
eg:
0. create a .dsc that builds a kernel with stock grsec
1. build it
2. integrate it into tails by doing x, y, z
All the best,
Jacob
