1 |
There is not a complete reference if not a lot of tips to close little |
2 |
doors instead, for example, you can implement a trusted path execution |
3 |
and forbid execution to nothing more that the common binaries and |
4 |
libraries (/bin /sbin /usr/bin /lib etc) to avoid exploits, you could |
5 |
restrict the interpretation of scripts (in the way of "perl |
6 |
myuntrusted_script.pl", forbidding people to use perl to avoid the |
7 |
TPE). You could restrict the missuse of TIOCSTI call to avoid fake |
8 |
instructions insertion in "an privilege user tty" by a compromised |
9 |
root (I don't know if this could be done in grsecurity). |
10 |
|
11 |
Another question that I think grsec lacks is the control of which |
12 |
SETUID binary could change to which uid (for example, permit only |
13 |
login to change to the uid 1000 and not 80), or forbid setuid if the |
14 |
user does not authenticate itself against the kernel (with a password |
15 |
in for example sshd, so remote exploits which affect priviledge parts |
16 |
of sshd only could change to uid 22 and not to root or those which |
17 |
affect login could be controlated) |
18 |
|
19 |
However there is a lot of questions to control a few documentation to it. |
20 |
|
21 |
|
22 |
2009/9/20, Marco Venutti <veeenrg@×××××.com>: |
23 |
> Hi, |
24 |
> |
25 |
> --[cut]-- |
26 |
> The jail bug were corrected long ago, and was limited to this module |
27 |
> only (in rsbac petitions pass to all modules that are stacked, not |
28 |
> only this one, and if only one module deny the request, is denied |
29 |
> forever though jail don't work properly). |
30 |
> --[cut]-- |
31 |
> |
32 |
> Since I'm a recent Linux user and I'm not a security cultured, |
33 |
> I've chosen GR-Security, as starting point, |
34 |
> because of its user-friendliness, in fact you can enforce, |
35 |
> the bare kernel, also if you are not deeply experienced |
36 |
> in Linux security... |
37 |
> this is my case, so I appreciate this opportunity! |
38 |
> |
39 |
> I've started from the "Gentoo Hardened Workstation" |
40 |
> profile and, then, I've done some gradm experiments... |
41 |
> these facts in the near past. |
42 |
> |
43 |
> I consider myself illiterate, in matter of security, |
44 |
> but I'd like to load, a little-little-bit, my lacunas, |
45 |
> just for the intellectual pleasure, I feel in satisfy |
46 |
> my curiousity. |
47 |
> |
48 |
> I'm not a professional, thus I don't have |
49 |
> servers to manage, just a couple of workstations, |
50 |
> so my needs are, probably, easier to fit... |
51 |
> no special high security enforcements are required; |
52 |
> this should also be good because gives me |
53 |
> the chance to start little, 'cause, in effect I've |
54 |
> little needs! |
55 |
> |
56 |
> Today is Sunday and I can read some docs, |
57 |
> I'm interested in RSBAC and I'm starting to read |
58 |
> RSBAC handbook, but at the moment I'm |
59 |
> using, yet, GR-Security beacuse of the previous |
60 |
> concept. |
61 |
> |
62 |
> I'll be glad if there's anybody willing |
63 |
> to indicate me any non-official-but-good how-to |
64 |
> and/or any sort of tip useful to get done |
65 |
> to "lock-down" my workstation about RSBAC, |
66 |
> but I'll appreciate GR-Sec.'s. |
67 |
> This section is intended to be a request of |
68 |
> a little help and does not mean: |
69 |
> "Is there anybody does my task, plese?" |
70 |
> I've specified the sense of the statement, |
71 |
> just to clear every possible ambiguity. |
72 |
> |
73 |
> |
74 |
> I wish you a good sunday afternoon ;-) |
75 |
> |