From: Ned Ludd <solar@gentoo.org>
To: gentoo-hardened@lists.gentoo.org
Cc: gentoo-dev@lists.gentoo.org, anthony@ectrolinux.com,
dmonnier@iu.edu, markusle@gmail.com, mtindal@paradoxpoint.com,
webkiller71@trsn.be, ps.m@gmx.net, bgb@itcnv.com,
co@kevquinn.com, tocharian@trilug.org
Subject: [gentoo-dev] Not considering dropping the hardened toolchain
Date: Tue, 21 Sep 2004 14:01:00 -0400 [thread overview]
Message-ID: <1095789660.8317.1590.camel@simple> (raw)
[-- Attachment #1: Type: text/plain, Size: 4898 bytes --]
Good afternoon gentlemen. Thanks for your feedback to the other thread.
Now due to the overwhelming positive feedback from the thread I'm faced
with trying to find enough tasks for everybody to do.
I will list a few things that I see as needing to be done.
------------------------------------------------------------------------
1) Re review the existing packages which filter-flags -fPIC and find
more creative solutions to them.
------------------------------------------------------------------------
2) Re review the existing packages which filter-flags -fstack-protector
and find more creative solutions to them.
------------------------------------------------------------------------
3) Better documentation.
Adam Mondl has started in on this task. So far he has developed a quick
intro of what's up with xorg and a hardened toolchain.
http://hardened.gentoo.org/hardenedxorg.xml
He is also working on a Hardened FAQ which has not been published yet.
http://tocharian.ath.cx/hardened/hardenedfaq.html
------------------------------------------------------------------------
4) A Comparative analysis of security approaches taken by distributions.
This should be written by somebody who has a fair amount of time on
his/her hands and should include such things as benchmarks.
Testing successful/unsuccessful exploitation rates.
(People like graphs and things they can visualize)
This would/should include why Gentoo has opted for PaX over RH's inhouse
Exec-Shield.
Google has a fair bit of info on this subject if you search long and
hard which clearly proves why for security PaX is clearly a superior
solution. (But do try to be objective in this)
You will need more than one machine for this test.
Suggested installs would be a hardened stage3 and fedora core 3.
The focus should be strictly on memory protections and not access
control.
Target audience should be medium advanced.
This may/should be written from an educational security perspective
(hint hint dmonnier @ IU EDU)
-----------------------------------------------------------------------
5) Look for flaws in the design of the hardened toolchain.
Are there any cases when using it may actually lower security? If so
when?
-----------------------------------------------------------------------
6) Review the existing method that the hardened toolchain uses.
Consider code cleanups which could make getting it to go mainstream
easier.
Currently it's a patch for gcc with some rules which control object code
creation and linking scenario's.
-----------------------------------------------------------------------
7) Learn to understand the gcc.specs and what they are all about.
http://dev.gentoo.org/~solar/toolchain/gcc/The_Specs_Language.txt
-----------------------------------------------------------------------
8) Supporting new arches.
Currently only x86/amd64/sparc64 are supported by the hardened
toolchain.
ppc/ppc64/s390 could be added easy enough. (need people with supporting
hardware)
mips/arm are having linking problems with crt files. (undefined
references to __csu_init/fini...)
As a rule of thumb here we want to support every arch that Gentoo does.
-----------------------------------------------------------------------
9) Embedded (SBC style) things.
Currently only x86-uclibc and ppc-uclibc support PIE with x86 being the
only semi complete one. Need to support other arches here.
-----------------------------------------------------------------------
10) Take a proactive effort and think of something yourself that could
use improvements.
The ones of you that that take a proactive effort on your own will more
likely make the team vs the ones of you that need hand holding.
But all help is desired. Be that simple suggestions or the occasional
xml document.
http://bugs.gentoo.org/show_bug.cgi?id=51853 where Kevin Quinn is
already getting to work is an example of one of you thats taking a
proactive effort on his own to help solve a long standing bug.
In addition to what Adam Mondl is doing with docs.
Those of you that feel intimidated don't be. You can always send
suggestions for the FAQ, proof read something, start a survey.
-----------------------------------------------------------------------
11) Hawk bugzilla!
Become active on the mailing lists. (-hardened/-security/others)
Not just 'hey XYZ does not compile', but try to help other users.
Do public relations. Do cover art. Do regression testing. Write
something with the aims of getting it published in a
book/magazine/other. Join the irc channel and offer help to users.
And mostly importantly try work with each other.
Thanks for your time and I look fwd to working with you guys (gals?).
--
Ned Ludd <solar@gentoo.org>
Gentoo (hardened,security,infrastructure,embedded,toolchain) Developer
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next reply other threads:[~2004-09-21 18:02 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-21 18:01 Ned Ludd [this message]
2004-09-21 18:25 ` [gentoo-dev] Not considering dropping the hardened toolchain Ferris McCormick
2004-09-21 21:19 ` [gentoo-dev] Re: [gentoo-hardened] " Dave Monnier, IT Security Office, Indiana University
2004-09-21 23:06 ` [gentoo-dev] " Duncan
2004-10-02 21:40 ` Michael Tindal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1095789660.8317.1590.camel@simple \
--to=solar@gentoo.org \
--cc=anthony@ectrolinux.com \
--cc=bgb@itcnv.com \
--cc=co@kevquinn.com \
--cc=dmonnier@iu.edu \
--cc=gentoo-dev@lists.gentoo.org \
--cc=gentoo-hardened@lists.gentoo.org \
--cc=markusle@gmail.com \
--cc=mtindal@paradoxpoint.com \
--cc=ps.m@gmx.net \
--cc=tocharian@trilug.org \
--cc=webkiller71@trsn.be \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox