1 |
On Mon, 11 Aug 2014 14:17:12 -0700 |
2 |
Mark Knecht <markknecht@×××××.com> wrote: |
3 |
|
4 |
> Hi all, |
5 |
> Just an introduction. First post here but _longtime_ Gentoo user. |
6 |
> (Early 2003 I think...) I ran Redhat before that starting in 1997. |
7 |
> |
8 |
> I'm a basic desktop end-user type. Self-employed, using KDE, |
9 |
> vlc/makemkv/handbrake, and multiple Virtualbox Win 7 VMs for trading |
10 |
> in the financial markets. I've converted my wife & 3 generations of my |
11 |
> family (parents in the 80's and son in his 20's) to Gentoo. None of |
12 |
> use native Windows anymore. I administer all the systems. |
13 |
|
14 |
Sounds like an OSS "model family". Congrats! ;-) |
15 |
|
16 |
> I'm starting to look down the road to a new main machine for me in |
17 |
> 6 months to 1 year. I'd like to start learning about the whole |
18 |
> hardened environment - what it can and cannot do, at least easily. If |
19 |
> I go this direction it's likely to try to be a fully encrypted disk |
20 |
> subsystem, including initrd. I'm not overly performance driven, but |
21 |
> that said I want to know where the cycles are going and don't want to |
22 |
> waste them if possible. |
23 |
|
24 |
Regarding system performance, my personal experience has been that the |
25 |
various overheads involved in typical "hardened" Linuxes are |
26 |
measurable, but not noticeable with most usage patterns. That said, |
27 |
there's one kind of "performance" which certainly degrades: |
28 |
Administration performance. You've got to have some time to debug all |
29 |
these tiny little problems which arise due to badly written software |
30 |
being incompatible with the system hardening etc. |
31 |
|
32 |
I'd always recommend encrypting your HDD, even for otherwise |
33 |
non-hardened systems. Performance losses aren't that bad, and the |
34 |
advantages are huge. (For example, think about sending in a laptop for |
35 |
a warranty repair. You don't want to wipe your hdd before, but you also |
36 |
don't want the vendor to be able to read it.) |
37 |
|
38 |
On the other hand, I've made some bad experiences with the |
39 |
initramdisk's required for that. Neither dracut nor genkernel did work |
40 |
satisfyingly, especially when SELinux entered the equation. I've been |
41 |
told the situation has improved in the meantime, but I've already |
42 |
switched to using a custom-written initramdisk. It's rock-solid, easily |
43 |
understandable and only does those things I want it to do, but those |
44 |
very well. (Of course, I'm willing to share the sources if someone is |
45 |
interested.) |
46 |
|
47 |
> Anyway, thought I'd say hi and look for any pointers about what to |
48 |
> read for a user such as myself. I'm going through the Gentoo Hardened |
49 |
> pages and trying to understand what model to use - grsecurity or |
50 |
> selinux. I'm leaning toward grsecurity but I don't have a good reason |
51 |
> one way or the other as of yet. |
52 |
|
53 |
There's much out there on the *net worth a look. Be sure to check out |
54 |
the Gentoo wiki: |
55 |
https://wiki.gentoo.org/index.php?title=Special%3APrefixIndex&prefix=Hardened&namespace=0 |
56 |
Oh, and also don't forget reading the help texts of the various |
57 |
grsecurity kernel options. Most of them are well-documented. |
58 |
|
59 |
Concerning "grsecurity vs SELinux", you're mixing up something here. |
60 |
There's SELinux, an "mandatory access control" (MAC) system available |
61 |
in the main-line kernels. And there's grsecurity/PaX, an extensive set |
62 |
of kernel patches which is included in hardened-sources. It includes an |
63 |
"RBAC" subsystem which is similar to SELinux in its purpose, but |
64 |
grsecurity is much more than that. It has kernel patches for "Kernel |
65 |
auditing" and "Chroot jail restrictions" to name only a few (as I |
66 |
said, check out the help texts!) and it includes the PaX suite, which |
67 |
dictates (among other things) that userland processes can't both write |
68 |
to a memory region and execute code from there, thereby avoiding a whole |
69 |
class of common exploits. All of those options are independent of your |
70 |
using RBAC or SELinux (or no MAC system at all). |
71 |
|
72 |
For starting out, I'd recommend using PaX and playing around with the |
73 |
other grsecurity options, but leaving RBAC and SELinux alone, as they |
74 |
add much more complexity and can be really overwhelming at the |
75 |
beginning. |
76 |
|
77 |
Later on, you can still add one of these MAC systems. (I personally do |
78 |
recommend SELinux, but that's a matter of taste, and as I said, don't |
79 |
worry about that now.) |
80 |
|
81 |
> I am interested in trying to do this in a VBox VM just as a |
82 |
> learning exercise and which I understand it won't be as secure as |
83 |
> doing it on bare metal I'd be very interested in hearing about others |
84 |
> experience in this area. |
85 |
|
86 |
I've never used Virtualbox, but I know hardened-sources kernels work |
87 |
very well in KVM environments. That said, it's certainly a wise |
88 |
decision to test substantive system changes beforehand in a virtualized |
89 |
environment. |
90 |
|
91 |
|
92 |
Regards, |
93 |
Luis Ressel |
94 |
|
95 |
PS: Wow, that mail I've just written somehow reminds me of Duncan. |