[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Is this mail list dead?



Tracy R Reed wrote:

> On Sat, Mar 17, 2001 at 12:55:02AM +0300, Pedro Rosa wrote:
> 
>> Note that Linux is not a OS with a very limited set of purposes. Don't 
>> tell me that attempts to enforce a security scheme at core bottom will 
>> not hinder such sections like real-time or clusters. So I think it is 
>> too risky to put two things in one boat.
> 
> 
> If it can be made a compile time option what have we got to lose? A LOT
> more people will consider using these new features if they are part of the
> kernel and visible in the make config. Linux is getting a horrible
> reputation for security which can affect its adoption rate. We should be
> doing everything possible to change that.
> 
Cool. I AGREE Linux is getting an horrible reputation.But I would prefer 
a solution a-la OpenBSD rather than seeing a dubious security scheme 
being implemented as a major feature all over the kernel and getting 
into all distros. Note: I have NOTHING against C2 or its successor. What 
I consider erroneous is to implement C2 inside the main trend. That will 
surely give birth to distros and builds on which security is WRONG from 
the very start. Because people will concentrate their ideas and efforts 
in one single conception. And their requirements may be quite far from 
what C2 really offers them. And if this happens we may forget about any 
possible "reputations". There will be one only...

I am speaking about this because I did see a completely stupid C2 
implementation. And one of the actors of the comedy is me... In fact I 
even directed the second act... That was a lesson: NEVER use a common 
security conception just because it's right on your desk... Or someone 
likes it...

Anyway, I think that, with the present way things are added to the 
kernel, we will not get anything good. I believe security should keep 
out of the main kernel makings (only a very small "supporting" set 
should be in it). But the traditional "patching" methods are getting too 
square and too straight to produce a good "secured" kernel version. I 
believe this is where the real security conceptions should start to see 
the kernel...

Ektanoor

-
Securedistros: A common list for all secured Linux distributions
Archive:       http://humbolt.nl.linux.org/lists/