1 |
El 16/06/10 11:26, Pavel Labushev escribió: |
2 |
> I think GRKERNSEC_BRUTE deserves a bit more explaination, as long as in |
3 |
> some (most?) cases it seems to be the single little trick that prevents |
4 |
> preforked apps to be eventually owned with no regard to ASLR, especially |
5 |
> on x86. |
6 |
> |
7 |
Updated the explanation a bit, I hope you find it more appropriate. |
8 |
> Also, maybe a reader should be advised to develop a policy to |
9 |
> autorestart preforked apps when the relevant records appear in the grsec |
10 |
> log? They are "Segmentation fault" and "Illegal instruction". And maybe |
11 |
> it deserves to be mentioned that SIGSEGV does not trigger the fork() |
12 |
> delay, so the autorestart policy which takes frequent SIGSEGV log |
13 |
> messages into account is a right thing. |
14 |
> |
15 |
Updated that too, I also commented that a small edit of the patch could |
16 |
also be valid to add the SIGSEGV signal to those controlled. |
17 |
> Btw, it's not "some delays" but the 30 seconds hardcoded in |
18 |
> grsecurity/grsec_sig.c. |
19 |
> |
20 |
Added also, I wrote some delays to make it more generic and easily |
21 |
accessible though I see that stating the delay helps a lot to see which |
22 |
are the consequences if the bug is triggered. |
23 |
|
24 |
Thanks for your comments :D |
25 |
|
26 |
El 13/06/10 15:30, ascii escribió: |
27 |
> seems nice to me, consider contacting someone @ |
28 |
> http://www.gentoo.org/proj/en/gdp/index.xml |
29 |
> |
30 |
Well I won't mind converting the doc to GuideXML if this document is |
31 |
interesting. All I need is a go ahead from someone on the Hardened team. |
32 |
> perhaps you'll also like this project |
33 |
> |
34 |
> http://lollobox.org/ |
35 |
> |
36 |
Seems cool, but a bit left over (also I don't currently own a working |
37 |
laptop) :/ It's a pity how most securization projects end up dying |
38 |
because people think great technical skills are needed to contribute. |