1 |
2009/9/19, Marco Venutti <veeenrg@×××××.com>: |
2 |
|
3 |
> |
4 |
> ---Question:--- |
5 |
> |
6 |
> It's a fact OpenBSD is a secure OS so, |
7 |
> if we put a OBSD-box online, we have |
8 |
> good chance it won't compromised, so |
9 |
> my question is the following: |
10 |
|
11 |
It's a fact that OpenBSD is a C2 capable security system (orange |
12 |
book), that is, is not a trusted OS because it lacks of MAC solutions |
13 |
|
14 |
|
15 |
> "Is it possible to obtain, approximately, |
16 |
> a Linux-box secure as an OBSD-box?" |
17 |
> |
18 |
> I know the intensive audit of OBSD and so on, |
19 |
> in fact I've written "approximately" and not "exactely". |
20 |
> |
21 |
It's possible to obtain a B1 (orange book) system under gnu/linux, so |
22 |
a trusted OS. |
23 |
|
24 |
> SELinux is included in the vanilla, |
25 |
> this sounds good, but mastering |
26 |
> SELinux is a long run |
27 |
> (a lot of time to invest in it) |
28 |
I think (maybe I'm wrong) Brad Spender published a bug that disabled |
29 |
SELinux because the LSM weakness |
30 |
|
31 |
> Another issue is that if you are running a |
32 |
> non-Red-Hat-derivative you won't find |
33 |
> any good tool for managing your own rules. |
34 |
> There are also pre-built policies, disciplining |
35 |
> most common services, but as every all-purpose |
36 |
> stuff it fits not very good our needs! |
37 |
> Writing policies with GNU/Emacs takes |
38 |
> too much time...this is an objective fact; |
39 |
> the subjective analisys is that it requires |
40 |
> much more time than I can spend, |
41 |
> considering my spare time. |
42 |
> |
43 |
|
44 |
Well, this is the true problem, making policies is one "do it |
45 |
yourself" question, to many things to control and the problem is that |
46 |
not everybody knows what to control. |
47 |
|
48 |
> AppArmor, recently included in the Ubuntu-family, |
49 |
> seems to be something like SELinux, but more |
50 |
> user-friendly. I mean both (SELinux and AppArmor) |
51 |
> have the intention to limitate damages coming from |
52 |
> a compromised service. If I'm wrong feel free to |
53 |
> clear my error. |
54 |
> |
55 |
Both works under LSM: |
56 |
http://lists.immunitysec.com/pipermail/dailydave/2009-July/005810.html |
57 |
http://grsecurity.net/~spender/cheddar_bay.tgz |
58 |
|
59 |
> Since I like increased restriction to /proc /tmp and so on, |
60 |
> and I appreciate randomisation goodies, this leads me to |
61 |
> look at RSBAC and GR-Security, in fact both have these features. |
62 |
> |
63 |
> RSBAC seems to be hard on first approach, |
64 |
> but much more flexible than GR-Security; |
65 |
> on the other hand GR-Security has a good |
66 |
> appeal if we're looking for an easy and fast way |
67 |
> to lock down a desktop or a laptop, since it |
68 |
> is "user-friendly ;-)" to install and set up |
69 |
> and grants a good level of security. |
70 |
> If I've understood correctly GR-Security could |
71 |
> be the best choice for desktop and RSBAC the |
72 |
> best choice for server...isn't it? |
73 |
> |
74 |
I agree with these |
75 |
|
76 |
|
77 |
> What about overhead...I mean I see GRsec. |
78 |
> has good performances, but I heard RSBAC |
79 |
> is not so-light...have you experienced this |
80 |
> slowlyness or it was, only present, in early |
81 |
> releases? |
82 |
> |
83 |
Overhead depends of what do you control. RSBAC is light too for me, |
84 |
the problem is that if you want log all READ_OPEN calls ( for example |
85 |
to log all open(O_RDONLY)) calls) the overhead would be high. |
86 |
|
87 |
> Back to subject of my post: |
88 |
> "How hard" is Linux...hardening? |
89 |
> |
90 |
> In the end, after long time tuning |
91 |
> do, these tools, grant us an high level security? |
92 |
> I mean: |
93 |
> Grsecurity had suffered of a return into libc exploit |
94 |
> that bypassed its protection. Grsecurity had also |
95 |
> a PaX-disabled bug in the past that expose |
96 |
> machines to risks. |
97 |
I think the main problem (I could be wrong) is that pax flags are |
98 |
marked in binaries (in userspace) in grsecurity. |
99 |
|
100 |
> |
101 |
> I heard RSBAC had problem with the jail solidity etc. |
102 |
> |
103 |
> Recently I've read something about a 2.6.30 bug |
104 |
> which makes useless, enforcement like SELinux, |
105 |
> AppArmor and so on... |
106 |
> |
107 |
> so I'm wondering if it is possible to harden Linux |
108 |
> the way you can leave it online with, approximately, |
109 |
> the same (high) probability, it won't be compromised |
110 |
> as OpenBSD does. |
111 |
|
112 |
The jail bug were corrected long ago, and was limited to this module |
113 |
only (in rsbac petitions pass to all modules that are stacked, not |
114 |
only this one, and if only one module deny the request, is denied |
115 |
forever though jail don't work properly). |