Re: Proposing amd64-hardened architecture for Debian
previously on this list Carlos Alberto Lopez Perez contributed:
> > Now shipping grsec is a really good idea. I'd like to see that as well.
>
> There has been an attempt to provide an official grsec-flavour of the
> Debian kernel, but it didn't worked:
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605090
Interesting and the opposition to it (aside from the driver backporting
and security patching amalgamation, the intricacies of which I am
unsure of, but a resolution looked offered) seems rather unreasonable
and born of mainly mis-understandings.
KMS - You can run X11 without priv I/O which is a major hole that can be
used to bypass things like selinux though you may need to change your
kernel boot line to enable KMS early. You can also run X11 with
priviledge seperation and why linux hasn't merged OpenBSDs patches yet
beats me.
XEN - I understand the practicalities of testing many architectures but
it is arguable that user testing on bare hardware is more accurate and
I fail to see why that should be a significant blocker. Virtualisation
as a security tool has also been proven to be a false premise in that it
adds complexity and new attack vectors like Timing attacks and so I see
many Grsec advocates avoiding it anyway. A message could be added to
the kernel description about it to stop users bugging devs of course.
SELINUX - RBAC is a more robust offering than SELINUX which has had
exploits due to LKM and whilst policies are more readily portable from
say Fedora, RBAC is actually far easier to use for a user, especially
the policy file and auto generation mode. Doesn't the kernel already
have multiple RBAC systems in the security config section so I see no
reason to argue it is undesired or should be patched out.
JIT/mprotect - You do need paxctl marking in the default everything
enabled configuration, for binaries like browsers (if I remember right
-m for firefox, -r for chrome ironically due to it's sandbox). -m is
needed for a few things like xfce4-mixer, various video playing but not
gnome-alsamixer and parole for some video types. I believe the mprotect
(-m) equivelent that blocks JIT (execution of compiled at runtime code)
is the part that OpenBSD has disabled globally by default and enabled
via malloc.conf. If it was widely known it would also generally be easy
to make code work with mprotect enabled and I don't believe the
performance hit would matter outside the context of this browsers js is
fastest but can only be shown by measurement and not users experience
especially when most care about rendering speed. Getting main stream
distros to ship grsec would be a first step to understanding the issue
of JIT as mentioned by Ted Unangst in his heartbleed page and making
the next step in security for all. If that happened Linux/Unix would
leapfrog Windows in all aspects of security and not just userland,
ironically primarily due to userland coding choices and this
education would greatly help OpenBSD and Gentoo Hardened too.
Brad Spenders comments were taken out of context, he did not say it
would be better if he just offered a .deb. He said you are more likely
to get that than him splitting out his RBAC and other parts. He feels
very strongly about RBAC and other features working in tandem to
prevent exploits. I am sure he had no intention of providing a .deb
and so this was him being polite whilst probably swearing in his head.
I don't know the full story but I believe he gave up on upstream
merging many years ago as he was spending more time arguing/educating
than working on security improvements. I think kernel.org is
probably much more receptive now the Windows kernel has some of these
features and their benefits have been proven but I expect he sees that
bridge as something he personally doesn't want to get sucked into.
The Windows kernel has some of these features that are largely unused
by userland but as they are now there more will and do use them (Windows
has progressed since DEP in XP which was completely unused and rather
rubbish). Linux and all Unix-like systems would really benefit if Linux
atleast got into a position akin to Windows where that could naturally
progress and I believe Unix userland devs may be more receptive to
these security problems once understood. whereas pressure building and
explosion is likely to cause fallout of multiple kinds ;-). A position
where responses surmount to, yeah but no-one runs grsec or
Gentoo hardened or OpenBSD anyway is unhealthy as a counter-response
yeah but many run Windows would simply blow up the thread.
p.s. Even if things break many will be happier still, OpenBSD
pro-actively breaks things because then bugs can be fixed properly
including firefox which mainly works just fine on OpenBSD. Debian and
all of Unix-like has benefitted from this bug-fixing so why not benefit
more.
--
_______________________________________________________________________
'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'
(Doug McIlroy)
In Other Words - Don't design like polkit or systemd
_______________________________________________________________________
I have no idea why RTFM is used so aggressively on LINUX mailing lists
because whilst 'apropos' is traditionally the most powerful command on
Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool
to help psychopaths learn to control their anger.
(Kevin Chadwick)
_______________________________________________________________________
Reply to: