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 |