grsecurity forums

I'd like to get as many suggestions as possible for a grsecurity quick-start guide I'm about to write. I plan the document to be able to show someone unfamiliar with grsecurity 2.0 to be able to install it on their system and be able to use all the important features, including the RBAC system. Some things I'm looking for:

* what would be a proper length?
* what topics should be discussed in greater length?
* would a reference card for the RBAC role, subject, and object modes be useful?
* what should be discussed about the RBAC system? (as a complete discussion of it would be far out of the scope of this document)

feel free to also suggest anything not covered by the questions above
thanks!

-Brad

Proper length > 2 double sided pages
Topics of greater length > compiling the kernel and how to apply
GRSecurity/pax
Screen Shots > how things should appear
> TS guide w/shots of how things shouldn't
appear

FYI This is minimalistic, but it would help me so maybe it will help others.

patching/compiling isnt a grsec issue, so i suggest you leave that out.
A good thing to describe in greater length is each CONFIG_ option and what it does, and the full ACL system (a bit like grsec 1 docs). I find the grsec 1 documentation quite complete.

-Rik

I think that a good info on how to "get dirty" .. like how to use learning mode and some default ACLs...

I'm new in grsec, and i'm having trouble in creating ACLs for certain utils, when allready using a default acl for / ... overiding that ACL is fine in daemons and services (not having problems there).. but things like .. init scripts and letting the "emerge" app work and install... its weird.. how I have a lot of permission denieds...
maybe its just cause i'm lame..

but I thing a good info would be not the "innerworkings" of grsec, but how to implement it.. and where should "newbies" enable ACLs (setuids, services, daemons, what else?)

I guess that once again a "hands down" approach on how to use effectively the new features (and old ones too) is in order...
Like roles.. what basic roles, to what functions..how to enable them..

Explaining how grsec works, and more tecnical details should be in a more extensive manual...

let-me just say congrats to you Spender, for the wonderfull work you've done.
And a reminder that if security tools aren't relatively easy they won't be used. (better to be easy, simple and effective, even limited, than full-blown and extremely dificult to use and implement)
And for that same reason, it's very important to have good documentation.

The first time I tried grsecurity, I would have wanted to see real life example how to secure some example system with grsecurity.

I think that quick-start guide should have three things:
1) introduction to grsecurity (1 page)
2) example case: step by step guide to secure example machine (few pages, only short description of every step)
3) printable one page reference-card (1 page)

Mh... seems like to be an "howto" rather than a "quick-start-guide"!
I suppose that a quick-stark should only present the caracteristics of GRSEC; in other words, it should show what grsecurity can do to improve the security on you linux box. In my opinion, this simple and _short_ guide should not contain the instruction on how to make grsec working, but should invite people to use grsec by understanding the benefits it will bring.
It's very different from a complete, long and _detailed_ document that many users will need in order to make it work. I use grsec2 on many production server, and I've really happy... but I must say that it wasn't easy to reach a good level of understanding with the only help of README file!

Bye, Claudio `sekko`

I really liked the grsec DOC for the 1.9.x series, really complete and exaustive.
To my eyes for 2.x it should be the same. Simple, Exaustive, Little (and simple) examples....

Examples always are helpful to me, so maybe some case studies showing different aspects of grsecurity in some appendices or something. Maybe that's not in the spirit of a "quick start" guide and should be in a separate in-depth doc. I'll leave that to Brad's judgment