1 |
On Wed, 2006-01-25 at 12:09 +0200, Jean Blignaut wrote: |
2 |
|
3 |
> I have often considered and even tried a couple of times to setup a |
4 |
> hardened box however I get confused between all the different options |
5 |
> and all the different implications. What with Selinux Grsecurity 1/2 |
6 |
> RSBAC PIE etc. etc. |
7 |
|
8 |
Each implementation solves a different subset of all "security" |
9 |
problems. |
10 |
|
11 |
PIE and SSP try to stop buffer overflows and code insertion attacks. |
12 |
They are "invasive" as they change how memory allocation and other low |
13 |
level things work and may break applications in quite interesting ways. |
14 |
Enabling them is easy. |
15 |
|
16 |
SELinux is a security policy framework, it doesn't care about buffer |
17 |
overflows, but manages what applications can do. You can lock down |
18 |
filesystem access, network access,... per application |
19 |
It's a lot more complicated to set up, but still manageable. The most |
20 |
problematic step is as far as I can tell teaching the access rules. |
21 |
Takes time and patience, but no black magic :-) |
22 |
|
23 |
GRSecurity is a somewhere in between, it may be the most useful for |
24 |
"normal" users, but I don't have enough experience with all of those to |
25 |
really comment on that. |
26 |
> |
27 |
> |
28 |
> Also the kernel patching concerns me a bit, I would much rather not |
29 |
> have to search around an battle to patch kernels my self if at all |
30 |
> possible. |
31 |
sys-kernel/* might have what you want - rsbac-sources and |
32 |
hardened-sources should be a good starting point. No need to reinvent |
33 |
the wheel ... |
34 |
|
35 |
> I don't get to upgrade the kernel on my production servers very often |
36 |
> since company policy is 0 downtime. |
37 |
> |
38 |
> |
39 |
> |
40 |
> Also Because these are production servers in use by 1000s of customers |
41 |
> I would have to find a hardened kernel (or what ever) that would have |
42 |
> as small an impact on the current workings and config of the systems |
43 |
> involved. |
44 |
You'd have to test on a spare box anyway :-) |
45 |
http://www.gentoo.org/proj/en/infrastructure/server-standards.xml might |
46 |
be a good starting point for the kernel settings, then you'll have to |
47 |
test until you can be reasonably sure that nothing fails. |
48 |
|
49 |
> |
50 |
> I have all my partitions formatted (and kernels built) with support |
51 |
> for security labels, but that's as far as I've gotten. Also the idea |
52 |
> of splitting up roots permissions into roles is an interesting |
53 |
> prospect but I've yet to find decent documentation on how to |
54 |
> implement/use POSIX ROLES |
55 |
There are many ways of increasing security - I've been using vserver for |
56 |
some time, helps a lot in service separation. The hardened profile is a |
57 |
nice starting point, but as I've had too many problems using it ~x86 on |
58 |
a desktop box I've reverted to the default profile and a vanilla kernel. |
59 |
The problems were mostly toolchain / compilation bugs, no "unstable" |
60 |
problems. It's recommendable for server usage. |
61 |
|
62 |
Hope that helps, |
63 |
|
64 |
Patrick |
65 |
-- |
66 |
Stand still, and let the rest of the universe move |