1 |
Low grsecurity level: |
2 |
|
3 |
linking restrictions |
4 |
fifo restrictions |
5 |
random pids |
6 |
enforcing nproc on execve() |
7 |
restricted dmesg |
8 |
random ip ids |
9 |
enforced chdir("/") on chroot |
10 |
|
11 |
Medium grsecurity level (include low grsec level) |
12 |
|
13 |
random tcp source ports |
14 |
failed fork logging |
15 |
time change logging |
16 |
signal logging |
17 |
deny mounts in chroot |
18 |
deny double chrooting |
19 |
deny sysctl writes in chroot |
20 |
deny mknod in chroot |
21 |
deny access to abstract AF_UNIX sockets out of chroot |
22 |
deny pivot_root in chroot |
23 |
denied writes of /dev/kmem, /dev/mem, and /dev/port |
24 |
/proc restrictions with special gid set to 10 (generalmente wheel) |
25 |
address space layout randomization |
26 |
removal of addresses from /proc//[maps|stat] |
27 |
|
28 |
high grsecurity level (include low and medium): |
29 |
|
30 |
additional /proc restrictions |
31 |
chmod restrictions in chroot |
32 |
no signals, ptrace, or viewing processes outside of chroot |
33 |
capability restrictions in chroot |
34 |
deny fchdir out of chroot |
35 |
priority restrictions in chroot |
36 |
segmentation-based implementation of PaX |
37 |
mprotect restrictions |
38 |
kernel stack randomization |
39 |
mount/unmount/remount logging |
40 |
kernel symbol hiding |
41 |
|
42 |
I took this from the grsecurity-hacktimes-v1.0.pdf. Let's see. |
43 |
|
44 |
Low level: it enforces the chroot creation a bit and protect against |
45 |
linking attacks. Protects against a few D.O.S. Is a very low low low |
46 |
low level of security (this and nothing is something like the same. |
47 |
|
48 |
Medium level: This introduces two things interesting, it protects |
49 |
memory devices from alteration (rootkits could do this). It harden the |
50 |
chroots creation closing some doors that could make people escape from |
51 |
it. I think it has not sense that ASLR appears here since the stack |
52 |
probably stays executable and so is not needed one return into libc |
53 |
attack to get success. The same for the restrictions to |
54 |
/proc/self/maps. |
55 |
|
56 |
High level: It enforces the no executable stack and heap and the |
57 |
mprotect restrictions to make it useful (so no memory could be |
58 |
simultaneously writeable and executable. Now is needed the ASLR |
59 |
approach and the hiding of address to make it useful against buffer |
60 |
overflows. |
61 |
|
62 |
It would be useful to activate Trusted Path Execution by default |
63 |
(maybe could appears in custom level?). |
64 |
|
65 |
2008/12/27 Grant <emailgrant@×××××.com>: |
66 |
>> Why don't you tell what you didn't understand to us explain it |
67 |
>> properly to you?. You can't assure nothing if you don't know what do |
68 |
>> you need to assure. |
69 |
>> You can't implement Mandatory Access Controls such as GRSEC rbac |
70 |
>> without a bit of known. You need to make one policy for your system |
71 |
>> and the kernel makes it enforcing their function. |
72 |
>> |
73 |
>> If you are not a sysadmin, how did you keep servers running?, to keep |
74 |
>> servers you need to know how does them work internaly (for example DNS |
75 |
>> rfc for DNS servers etc.). |
76 |
> |
77 |
> When I say I'm not a real sysadmin, I mean I have many duties and I'm |
78 |
> not able to dive all the way in with sysadmin stuff. This is due to |
79 |
> time constraints. |
80 |
> |
81 |
>> As bad is not getting one MAC system running (as the RBAC of |
82 |
>> grsecurity) as get one incorrectly configured running, for example |
83 |
>> granting all capabilities (CAP_SYS_RAWIO...) to the user running |
84 |
>> skype. GRSEC has one TPE function in himself read about it. |
85 |
>> |
86 |
>> Sorry but you have to read documentation (start for example with |
87 |
>> gentoo hardened docs). |
88 |
> |
89 |
> You're right. I thought that I was hardening my system just by |
90 |
> running a hardened profile and a hardened kernel at the "Medium" |
91 |
> Grsecurity setting. Does that provide no extra security if I don't |
92 |
> configure it beyond that? |
93 |
> |
94 |
> - Grant |
95 |
> |
96 |
> |
97 |
>>>> Without hardened userland only in access controls. You can implement |
98 |
>>>> for example one Trusted Path Execution with LIDS, RSBAC, GRSEC or |
99 |
>>>> SELinux. They could try to stop crackers that gain unpriviledge access |
100 |
>>>> to the host (with a remote exploit for example) to execute exploits to |
101 |
>>>> scale priviledges. They could give you one least priviledge approach |
102 |
>>>> (as PaX does) and other useful things, as isolation of daemons, |
103 |
>>>> resources controls. And a lot of more. With TPE however, untrusted |
104 |
>>>> scripts (exploits) could be launched without execution rights, and |
105 |
>>>> even restricting the use of perl and python, you must grant your users |
106 |
>>>> the access to bash. |
107 |
>>> |
108 |
>>> Thank you for taking the time to explain, but I'm afraid I don't |
109 |
>>> understand. I'm looking for things I can implement that don't require |
110 |
>>> me to understand their inner workings. This is not ideal, but I only |
111 |
>>> have so much time to devote to sysadmin duties since I'm not a real |
112 |
>>> sysadmin. My server runs a hardened profile because it hasn't caused |
113 |
>>> any problems, but running a hardened profile on my desktops has proven |
114 |
>>> to be too difficult. All of my systems run a hardened kernel but the |
115 |
>>> only hardened feature I've enabled in the kernel is Grsecurity set to |
116 |
>>> medium or low depending on the system. |
117 |
>>> |
118 |
>>> Do the hardened profile and hardened kernels do me any good without |
119 |
>>> further configuration? |
120 |
>>> |
121 |
>>> - Grant |
122 |
>>> |
123 |
>>>>>> In terms of userland, non hardened profile doesn't protect you at all |
124 |
>>>>>> against buffer overflows, you are removing one important security |
125 |
>>>>>> layer. SSP protects you against buffer overflows in terms that the |
126 |
>>>>>> vulnerable application gets killed when the canary is modified before |
127 |
>>>>>> the execution of the arbitrary code. PIE protects you against return |
128 |
>>>>>> into libc attacks that doesn't need an executable stack. PaX is not |
129 |
>>>>>> perfect and needs them as complementary solutions. For example I think |
130 |
>>>>>> that RANDEXEC was removed from PaX time ago, one buffer overflow that |
131 |
>>>>>> uses return into libc attack could be succesfully against one |
132 |
>>>>>> non-hardened binary. Since skype is a network oriented software... |
133 |
>>>>> |
134 |
>>>>> In what situations is a hardened kernel useful? |
135 |
>>>>> |
136 |
>>>>> - Grant |
137 |
> |
138 |
> |