[gentoo-hardened] Giving a hand with docs

[gentoo-hardened] Giving a hand with docs

[klondike]

[-- Attachment #1: Type: text/plain, Size: 785 bytes --]

Hi,
As things stand right now I have 3 or 4 days to write a small work on
how Gentoo hardened, specially the toolchain, does its best to protect
against programming flaws before they are discovered.

I asked if there was a problem on trying to write the work for it to be
either an improvement to or a new Gentoo doc and my teacher said there
was no problem as long as I would appear as coauthor of the doc and it
was easily understandable to somebody new to this amazing world.

So the question now is, is there any document which needs to be written
/ taken care for?

PS: I'm sorry for disappearing again for 2 months, but with calendar and
the way of teaching at my university, work usually comes in batchs and
when one comes I have no time to do other things :(


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

[gentoo-hardened] Re: Giving a hand with docs

[klondike]

Well for now I have written a 12 page doc praying the goodness of
Gentoo Hardened.

On that document I explain how two common attacks (Buffer overflow and
Null Pointer Dereference exploit) work and the implications they have.
After that I expose how the toolchain improvements act against them
and expose, along with that, other kernel protection methods provided
by grsecurity. Finally I expose a table with an estimation of the new
risk of an attack after enabling them and write a few lines about the
possible incompatibilities which may arise.

I hope you like it and would also like your comments.

Also ask for excuses because maybe the document has a few imprecisions
or white lies due to a bad understanding, feel free to outline them
to.

Francisco Blas Izquierdo Riera (klondike)

[gentoo-hardened] Re: Giving a hand with docs

[klondike]

[-- Attachment #1: Type: text/plain, Size: 33 bytes --]

Forgot the attachment adding it.

[-- Attachment #2: GentooHardenedWhy.odt --]
[-- Type: application/vnd.oasis.opendocument.text, Size: 23606 bytes --]

Re: [gentoo-hardened] Re: Giving a hand with docs

[Pavel Labushev]

13.06.2010 17:15, klondike пишет:
> Well for now I have written a 12 page doc praying the goodness of
> Gentoo Hardened.

Well done, thank you! That's what I'm gonna show my coworkers when they
ask me about what Hardened is.

> Also ask for excuses because maybe the document has a few imprecisions
> or white lies due to a bad understanding, feel free to outline them
> to.

I think GRKERNSEC_BRUTE deserves a bit more explaination, as long as in
some (most?) cases it seems to be the single little trick that prevents
preforked apps to be eventually owned with no regard to ASLR, especially
on x86.

Also, maybe a reader should be advised to develop a policy to
autorestart preforked apps when the relevant records appear in the grsec
log? They are "Segmentation fault" and "Illegal instruction". And maybe
it deserves to be mentioned that SIGSEGV does not trigger the fork()
delay, so the autorestart policy which takes frequent SIGSEGV log
messages into account is a right thing.

Btw, it's not "some delays" but the 30 seconds hardcoded in
grsecurity/grsec_sig.c.

[gentoo-hardened] Re: Giving a hand with docs

[klondike]

[-- Attachment #1.1: Type: text/plain, Size: 1785 bytes --]

El 16/06/10 11:26, Pavel Labushev escribió:
> I think GRKERNSEC_BRUTE deserves a bit more explaination, as long as in
> some (most?) cases it seems to be the single little trick that prevents
> preforked apps to be eventually owned with no regard to ASLR, especially
> on x86.
>   
Updated the explanation a bit, I hope you find it more appropriate.
> Also, maybe a reader should be advised to develop a policy to
> autorestart preforked apps when the relevant records appear in the grsec
> log? They are "Segmentation fault" and "Illegal instruction". And maybe
> it deserves to be mentioned that SIGSEGV does not trigger the fork()
> delay, so the autorestart policy which takes frequent SIGSEGV log
> messages into account is a right thing.
>   
Updated that too, I also commented that a small edit of the patch could
also be valid to add the SIGSEGV signal to those controlled.
> Btw, it's not "some delays" but the 30 seconds hardcoded in
> grsecurity/grsec_sig.c.
>   
Added also, I wrote some delays to make it more generic and easily
accessible though I see that stating the delay helps a lot to see which
are the consequences if the bug is triggered.

Thanks for your comments :D

El 13/06/10 15:30, ascii escribió:
> seems nice to me, consider contacting someone @
> http://www.gentoo.org/proj/en/gdp/index.xml
>   
Well I won't mind converting the doc to GuideXML if this document is
interesting. All I need is a go ahead from someone on the Hardened team.
> perhaps you'll also like this project
>
> http://lollobox.org/
>   
Seems cool, but a bit left over (also I don't currently own a working
laptop) :/ It's a pity how most securization projects end up dying
because people think great technical skills are needed to contribute.

[-- Attachment #1.2: GentooHardenedWhy.odt --]
[-- Type: application/vnd.oasis.opendocument.text, Size: 23711 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-hardened] Re: Giving a hand with docs

[Pavel Labushev]

27.06.2010 10:50, klondike пишет:

> Updated that too, I also commented that a small edit of the patch could
> also be valid to add the SIGSEGV signal to those controlled.

OK, but this part brings some degree of uncertainty:

"though if you do, your system would be prone to a DOS attack if any of
your forking daemons has a memory bug."

... It sounds like if you have a single buggy daemon, it would make the
_whole_ system be prone to a DoS attack, while it's just the daemon
itself becomes at risk. Maybe change it to: "though if you do, and if
any of your forking daemons has a memory bug, that daemon would be prone
to a DOS attack ."?

Re: [gentoo-hardened] Re: Giving a hand with docs

[Daniel Kuehn]

On Tue, 29 Jun 2010 15:40:10 +0800
Pavel Labushev <p.labushev@gmail.com> wrote:

> 27.06.2010 10:50, klondike пишет:
> 
> > Updated that too, I also commented that a small edit of the patch could
> > also be valid to add the SIGSEGV signal to those controlled.
> 
> OK, but this part brings some degree of uncertainty:
> 
> "though if you do, your system would be prone to a DOS attack if any of
> your forking daemons has a memory bug."
> 
> ... It sounds like if you have a single buggy daemon, it would make the
> _whole_ system be prone to a DoS attack, while it's just the daemon
> itself becomes at risk. Maybe change it to: "though if you do, and if
> any of your forking daemons has a memory bug, that daemon would be prone
> to a DOS attack ."?
> 

Or say that the daemon would open the system up to an DoS attack utilizing that
daemon.
Because if one daemon is susceptible to an DoS, it does mean that the system is
susceptible to an DoS because that daemon resides on that system.

-- 
Kind regards
Daniel Kuehn