1 |
> Why don't you tell what you didn't understand to us explain it |
2 |
> properly to you?. You can't assure nothing if you don't know what do |
3 |
> you need to assure. |
4 |
> You can't implement Mandatory Access Controls such as GRSEC rbac |
5 |
> without a bit of known. You need to make one policy for your system |
6 |
> and the kernel makes it enforcing their function. |
7 |
> |
8 |
> If you are not a sysadmin, how did you keep servers running?, to keep |
9 |
> servers you need to know how does them work internaly (for example DNS |
10 |
> rfc for DNS servers etc.). |
11 |
|
12 |
When I say I'm not a real sysadmin, I mean I have many duties and I'm |
13 |
not able to dive all the way in with sysadmin stuff. This is due to |
14 |
time constraints. |
15 |
|
16 |
> As bad is not getting one MAC system running (as the RBAC of |
17 |
> grsecurity) as get one incorrectly configured running, for example |
18 |
> granting all capabilities (CAP_SYS_RAWIO...) to the user running |
19 |
> skype. GRSEC has one TPE function in himself read about it. |
20 |
> |
21 |
> Sorry but you have to read documentation (start for example with |
22 |
> gentoo hardened docs). |
23 |
|
24 |
You're right. I thought that I was hardening my system just by |
25 |
running a hardened profile and a hardened kernel at the "Medium" |
26 |
Grsecurity setting. Does that provide no extra security if I don't |
27 |
configure it beyond that? |
28 |
|
29 |
- Grant |
30 |
|
31 |
|
32 |
>>> Without hardened userland only in access controls. You can implement |
33 |
>>> for example one Trusted Path Execution with LIDS, RSBAC, GRSEC or |
34 |
>>> SELinux. They could try to stop crackers that gain unpriviledge access |
35 |
>>> to the host (with a remote exploit for example) to execute exploits to |
36 |
>>> scale priviledges. They could give you one least priviledge approach |
37 |
>>> (as PaX does) and other useful things, as isolation of daemons, |
38 |
>>> resources controls. And a lot of more. With TPE however, untrusted |
39 |
>>> scripts (exploits) could be launched without execution rights, and |
40 |
>>> even restricting the use of perl and python, you must grant your users |
41 |
>>> the access to bash. |
42 |
>> |
43 |
>> Thank you for taking the time to explain, but I'm afraid I don't |
44 |
>> understand. I'm looking for things I can implement that don't require |
45 |
>> me to understand their inner workings. This is not ideal, but I only |
46 |
>> have so much time to devote to sysadmin duties since I'm not a real |
47 |
>> sysadmin. My server runs a hardened profile because it hasn't caused |
48 |
>> any problems, but running a hardened profile on my desktops has proven |
49 |
>> to be too difficult. All of my systems run a hardened kernel but the |
50 |
>> only hardened feature I've enabled in the kernel is Grsecurity set to |
51 |
>> medium or low depending on the system. |
52 |
>> |
53 |
>> Do the hardened profile and hardened kernels do me any good without |
54 |
>> further configuration? |
55 |
>> |
56 |
>> - Grant |
57 |
>> |
58 |
>>>>> In terms of userland, non hardened profile doesn't protect you at all |
59 |
>>>>> against buffer overflows, you are removing one important security |
60 |
>>>>> layer. SSP protects you against buffer overflows in terms that the |
61 |
>>>>> vulnerable application gets killed when the canary is modified before |
62 |
>>>>> the execution of the arbitrary code. PIE protects you against return |
63 |
>>>>> into libc attacks that doesn't need an executable stack. PaX is not |
64 |
>>>>> perfect and needs them as complementary solutions. For example I think |
65 |
>>>>> that RANDEXEC was removed from PaX time ago, one buffer overflow that |
66 |
>>>>> uses return into libc attack could be succesfully against one |
67 |
>>>>> non-hardened binary. Since skype is a network oriented software... |
68 |
>>>> |
69 |
>>>> In what situations is a hardened kernel useful? |
70 |
>>>> |
71 |
>>>> - Grant |