Gentoo Archives: gentoo-hardened

From: "Javier J. Martínez Cabezón" <tazok.id0@×××××.com>
To: gentoo-hardened@l.g.o
Subject: Re: [gentoo-hardened] "How hard" is Linux kernel-side hardening?
Date: Sun, 20 Sep 2009 11:24:44
Message-Id: 897813410909200424y43de28dbq65be20788a7445bd@mail.gmail.com
In Reply to: [gentoo-hardened] "How hard" is Linux kernel-side hardening? by Marco Venutti
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).

Replies

Subject Author
Re: [gentoo-hardened] "How hard" is Linux kernel-side hardening? Marco Venutti <veeenrg@×××××.com>