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