Re: Hardening (was: Re: tor: update to 0.2.9.9)

[ng0]

ng0 <address@hidden> writes:

> Leo Famulari <address@hidden> writes:
>
>> On Tue, Jan 24, 2017 at 09:18:55PM +0000, ng0 wrote:
>>> ng0 <address@hidden> writes:
>>> > Leo Famulari <address@hidden> writes:
>>> >>> It would be great to see some movement on this during this
>>> >>> year. I volunteer to help with it, though I don't have as much
>>> >>> experience with SELinux (and only basic experience with
>>> >>> GrSecurity without a modular kernel like GuixSD uses).
>>> >>
>>> >> Yes, this effort needs a champion.
>>> 
>>> No, I would say this needs an effort of more than one person. At
>>> best a team of people who either are willing to learn about
>>> system hardening or already know enough, maybe even a combination
>>> of both to share knowledge :)
>>
>> Sure, the more people the better. But so far, not a single person has
>> begun working on it, so I'd be happy with just one.
>
> I feel confident enough to do it, but I also know that I am
> overloaded with packages and services I work on.
>
> For starters, I think we could have an "hardened-wip" branch on
> savannah (I can't commit anyway directly) and that we can target
> SELinux for now, look at Hardened-gentoo and other systems how
> they solve issues.  Afterwards we need to address the toolchain
> level, which to our advantage can be an make and break by hydra
> and everyone who wants to contribute to fixing issues can run
> their system from the hardening-toolchain-wip branch to
> contribute to fixing all the breaking applications.
>
> Then we need to discuss wether we want to provide this by default
> (my choice) OR if we want to offer a branch-choice model.
> Supporting both vanilla and hardened might take some more burden
> on fixing issues, that's why I'm all for forming a team of people
> who work on this, and when they no longer want to, other people
> join the rest of the old team, etc.
>
> Right now I'm trying to get uclib-ng done for a while, and when
> this is added, we could at some point handle more than one
> toolchain (and hardened), where it gets complicated.

Actually, the statement about more libcs (musl, glibc, uclibc)
making it all more complicated isn't true. In 99% of cases
uclibc-ng just works as good as glibc and musl is the one odd
bird you have to patch applications for sometimes, but even there
enough work has already been done by other systems.

-- 
♥Ⓐ  ng0 -- https://www.inventati.org/patternsinthechaos/