There is not a complete reference if not a lot of tips to close little
doors instead, for example, you can implement a trusted path execution
and forbid execution to nothing more that the common binaries and
libraries (/bin /sbin /usr/bin /lib etc) to avoid exploits, you could
restrict the interpretation of scripts (in the way of "perl
myuntrusted_script.pl", forbidding people to use perl to avoid the
TPE). You could restrict the missuse of TIOCSTI call to avoid fake
instructions insertion in "an privilege user tty" by a compromised
root (I don't know if this could be done in grsecurity).

Another question that I think grsec lacks is the control of which
SETUID binary could change to which uid (for example, permit only
login to change to the uid 1000 and not 80), or forbid setuid if the
user does not authenticate itself against the kernel (with a password
in for example sshd, so remote exploits which affect priviledge parts
of sshd only could change to uid 22 and not to root or those which
affect login could be controlated)

However there is a lot of questions to control a few documentation to it.


2009/9/20, Marco Venutti <veeenrg@...>:
> Hi,
>
> --[cut]--
> The jail bug were corrected long ago, and was limited to this module
> only (in rsbac petitions pass to all modules that are stacked, not
> only this one, and if only one module deny the request, is denied
> forever though jail don't work properly).
> --[cut]--
>
> Since I'm a recent Linux user and  I'm not a security cultured,
> I've chosen GR-Security, as starting point,
> because of its user-friendliness, in fact you can enforce,
> the bare kernel, also if you are not deeply experienced
> in Linux security...
> this is my case, so I appreciate this opportunity!
>
> I've started from the "Gentoo Hardened Workstation"
> profile and, then, I've done some gradm experiments...
> these facts in the near past.
>
> I consider myself illiterate, in matter of security,
> but I'd like to load, a little-little-bit, my lacunas,
> just for the intellectual pleasure, I feel in satisfy
> my curiousity.
>
> I'm not a professional, thus I don't have
> servers to manage, just a couple of workstations,
> so my needs are, probably, easier to fit...
> no special high security enforcements are required;
> this should also be good because gives me
> the chance to start little, 'cause, in effect I've
> little needs!
>
> Today is Sunday and I can read some docs,
> I'm interested in RSBAC and I'm starting to read
> RSBAC handbook, but at the moment I'm
> using, yet, GR-Security beacuse of the previous
> concept.
>
> I'll be glad if there's anybody willing
> to indicate me any non-official-but-good how-to
> and/or any sort of tip useful to get done
> to "lock-down" my workstation about RSBAC,
> but I'll appreciate GR-Sec.'s.
> This section is intended to be a request of
> a little help and does not mean:
> "Is there anybody does my task, plese?"
> I've specified the sense of the statement,
> just to clear every possible ambiguity.
>
>
> I wish you a good sunday afternoon ;-)
>