Gentoo Archives: gentoo-hardened

From: Ed W <lists@××××××××××.com>
To: gentoo-hardened@l.g.o
Subject: Re: [gentoo-hardened] Remove toolchain?
Date: Mon, 01 Feb 2010 14:02:59
Message-Id: 4B66D81E.7030908@wildgooses.com
In Reply to: [gentoo-hardened] Remove toolchain? by Hinnerk van Bruinehsen
1 On 01/02/2010 12:35, Hinnerk van Bruinehsen wrote:
2 > s one thing which disturbs me: Since Gentoo (and hardened
3 > Gentoo) is sourcebased, i'll need a complete toolchain to keep the
4 > system up to date.
5 >
6 > I don't like the idea of giving this tools to someone who might
7 > compromise the server.
8 >
9 > Is there a way to keep the toolchain on a thumbdrive or in an encrypted
10 > partition, so that a possible attacker can't use it, while I have still
11 > access to it? Does a how-to or a guide exist, which coud guide me
12 > through the process of setting it up correctly
13
14 You have a 90% working solution through compiling and distributing
15 binary packages. The constraints are that you need to sync your USE
16 flags and compile flags, or use multiple binary repositories.
17
18 I actually use something partially similar to keep a bunch of
19 linux-vservers in sync - I maintain a set of custom profiles which
20 inherit from the hardened profile and these are customised for each
21 server "type", eg I have a hardened-apache and a hardened-nginx and a
22 hardened-postfix, etc profile. I use linux-vservers so that I can have
23 very fine grained app installations and flexibility to swap hardware (eg
24 nearly all web applications get their own complete virtual machine...).
25 Largely the USE flags/compile flags are all set in my profiles, but I do
26 relax this a little bit as I allow toolchain on each vserver (which you
27 are avoiding, so vary your setup)
28
29 There are some limitations with binary packages in that new users don't
30 seem to get created correctly (see various history on the -embedded
31 list). This can be worked around in general, but just beware of that
32 small issue
33
34 One feature that I like but don't exploit about linux-vservers is that
35 in theory you can easily use the host tools to test/verify the guest
36 installation - this means double trouble if the host is compromised, but
37 potentially allows interesting avenues to detect compromised guests by
38 examining them from the host. Probably similar things can be done with
39 all other virtualisation solutions also.
40
41 Quick checklist is that whatever solution you pick it should DEFINITELY
42 include virtualised guest right from the word go...
43
44 I have found gentoo a very good fit for maintaining a long term
45 installation without the pain of re-installs which you eventually
46 encounter with Redhat/debian solutions. However, I would suggest that
47 the base level of experience required to manage the server is higher,
48 but the payoff is much greater control and ease of management. Over to
49 you to decide if these tradeoffs are manageable, but big thumbs up from
50 me for our needs.
51
52 Good luck
53
54 Ed W