Gentoo Archives: gentoo-dev

From: John Nilsson <john@×××××××.nu>
To: John Nilsson <john@×××××××.nu>
Cc: Brian Harring <bdharring@××××.edu>, Steven Elling <ellings@×××××.com>, gentoo-dev@g.o
Subject: Re: [gentoo-dev] Portage through SSH
Date: Mon, 01 Sep 2003 16:55:04
Message-Id: 3F5379E5.7070806@milsson.nu
In Reply to: Re: [gentoo-dev] Portage through SSH by John Nilsson
1 Or rather use gentoo to manage a number of lfs-systems. =)
2
3 -John
4
5 John Nilsson wrote:
6
7 > How about the ability to install a gentoo system on a 20MB partition?
8 > The ability make a profile not containing gcc, glibc and portage would
9 > be nice.
10 >
11 > -John
12 >
13 >
14 > Brian Harring wrote:
15 >
16 >>
17 >> On Monday, September 1, 2003, at 02:04 AM, Steven Elling wrote:
18 >>
19 >>> On Sunday 31 August 2003 13:14, John Nilsson wrote:
20 >>>
21 >>>> Some requirement thoughts:
22 >>>> A network of gentoo hosts should have only one portage processing
23 >>>> server
24 >>>> and any number of installation leafs.
25 >>>>
26 >>>> First of all portage needs to easily handle more than one installation.
27 >>>> Second the "leaf-installations" should have a very strict minimum
28 >>>> requiremnts.
29 >>>> Third redundancy is probably important. The information to restore a
30 >>>> lost "leaf" should be availible on booth the portage host and on the
31 >>>> leaf it self.
32 >>>
33 >>>
34 >>>
35 >>> I think this is something sorely needed. I'm reading some books on
36 >>> securing
37 >>> Linux servers and on a bastion host (or any host in a DMZ for that
38 >>> matter)
39 >>> there should not be a compiler or any include files. The reason why
40 >>> is if
41 >>> the system were compromised it would limit the cracker from compiling
42 >>> and
43 >>> installing a root kit.
44 >>
45 >>
46 >> It would limit them to having to install a root kit, or install a
47 >> compiler (and needed headers). Kind of pointless though, since if
48 >> they've managed to elevate their rights to the level of installing a
49 >> root kit, lack of a compiler is merely an annoyance to them at that
50 >> point.
51 >> Maybe I'm missing something, but this strikes me as nothing more then
52 >> an annoyance to someone after they've *already* cracked the box. To
53 >> me it's like littering tacks throughout your house, hoping to slow
54 >> down the robber who has already broke into your house- yeah, it'll
55 >> likely slow him down, but it's also a makes things a pain in the arse
56 >> for the home owner...
57 >> Of course, as I said, perhaps I'm missing something...
58 >>
59 >>> As it stands right now, a Gentoo based system
60 >>> requires gcc, includes, and all their friends to operate and be
61 >>> managable
62 >>> (Note: Gentoo alone does not have this problem. RedHat, Debian, and
63 >>> every
64 >>> kitchen sink distro does the same).
65 >>>
66 >>> I like Gentoo, but it is not a viable option to the security concious
67 >>> and
68 >>> enterprises because it does not support such a feature in addition to
69 >>> central package management.
70 >>
71 >>
72 >> I'd agree on the central package management aspect- the ability to
73 >> control and push updates out (after securing the method/control
74 >> channels in some manner) would be quite nice. None the less, I'd tend
75 >> to think (opinion of course) gentoo is quite fine from a security
76 >> standpoint. You're reasons for it not being viable?
77 >>
78 >>> Gentoo is no alone however.
79 >>>
80 >>> For reference, the book I am reading is "Building Secure Servers with
81 >>> Linux"
82 >>> (ISBN: 0-596-00217-3). The book is written by Michael D. Bauer and
83 >>> published by O'Reilly.
84 >>
85 >>
86 >> I'll probably end up taking a look at it (got to love safari),
87 >> specific chapter that this is suggested in?
88 >> ~bdh
89 >>
90 >>>
91 >>>
92 >>> --
93 >>> gentoo-dev@g.o mailing list
94 >>>
95 >>
96 >>
97 >> --
98 >> gentoo-dev@g.o mailing list
99 >>
100 >
101 >
102 >
103 > --
104 > gentoo-dev@g.o mailing list
105 >
106
107
108
109 --
110 gentoo-dev@g.o mailing list