Re: Is this mail list dead?

[Pedro Rosa <Pedro.Rosa@ksu.ru>]

Casey Schaufler wrote:

> Pedro Rosa wrote:
> 
>> Enforcing such
>> things like C2 into the kernel from start, can give a huge cost in
>> performance and may hinder other security schemes.
> 
> 
> What makes you think that meeting the C2 (CAPP in CCese)
> requirements is going to have a "huge cost" in performance?
> What makes you think it will hinder other security schemes?
> I've been building C2 and B1 systems since the 80's and
> although I've seen bad implementations have performance
> impact, I've also seen good ones that do not.

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.

Yes, the position of C2 out of the core-bottom may hinder Linux, for the 
fact that it will never have a 99,99% secured architecture. However, I'm 
pretty convinced that 99,99% of its users wouldn't need such 
requirement. For such ultra-security there should be other OSes (OpenBSD 
for example).

On what concerns hindering other security systems, I consider the 
psychologic point of view. I cannot consider C2 as a scheme "for all 
cases". As an example among many. Well some people prefer to use "crack 
traps" rather than thinking about applying C2 to every user's brain... 
In fact this point is still the biggest security breach of all. And no 
matter how many threats and rays you spend on users, 99% of security 
breaches are caused by them...

Now why I am talking about this? Well, I saw a near C2 implementation. 
The level of security was extrapolated to the impossible because there 
was a series of rules and possiblities that were inter-exclusive. The 
system was a monster and people felt like working in something worse 
than the Gulag (and, oh damn, Democracy is now working here... So people 
were talking the  Hell about it) So the concept was completely changed. 
Now people can do nearly all they may want from the system. With a very 
small set of restrictions. To observe that people don't pass the limits 
a few monitors and "traps" were set. They are mostly set to check for 
attempts on setting trojans, viruses or break-ins. 
  
Why this thing had started from C2? Because someone read about C2, about 
the C2 implementations, about one thing that is "C2 compatible"... So 
let's go on C2! Why? Because it is there from start and everyone speaks 
about it... Why to break the head with other schemes, protocols, 
methods? But it is amazing how this highly american protocol can turn a 
whole network into a fascist concentration camp (it only lacked the 
admins in Waffen SS uniforms). Well, the fault is not exactly on the 
protocol itself...

> 
>> And, by itself, C2 is quite costy to be implemented (time, performance,
>> stability and money are the factors).
> 
> 
> The kernel bit (security audit trail) is not so bad.
> What are your stability issues?

Well in theory none. In practic, I'm pretty sure that it will take not 
less than a year for an implementation to work out. That's pretty well 
seen on kernel development timelines.

> 
>> Frankly, I would apply C2 only and
>> exclusively in a very few cases.
> 
> 
> C2 provides basic system functionality. UserIDs, Descretionary
> Access Control (e.g. mode bits) are things U2X users don't
> even think about.

Correct. But there are many cases when this basic things are not even 
needed. For example in my own machine... Why do I need C2 on my own 
machine?

> 
>> A C2 implementation should be something like how we see LIDS, FreeSWAN
>> and other systems now - a patch. And give sysadmins/users the right to
>> choose what they need.  Don't think that such thing becomes only
>> valuable once Linus implements it as a main kernel feature.
> 
> 
> In Irix audit is a module you can choose at installation time.
> On Linux, we expect to make it available as a loadable module.
> Or, if you prefer, you can compile any trace of it out.

Even a module gives a load on other pieces of the kernel. And note that 
we are speaking not about a device but about a concept that affects 
several sections of the kernel (file systems for example). You cannot 
implement such a protocol just by adding a module.

> 
> 
> Any pervasive kernel facility, and audit will be, no
> question about that, that you try to maintain on the side
> gets broken every time someone changes anything. I have years
> of experiance on this, and can show you the scars.

Correct. And I think I see your scars. But I believe that the case of 
good security demands a case of speciality. Adding something about 
security to the main developer trend is nothing more than prestige. 
Security should remain private and "specialized" to be security with a 
big "S". And sincerly, I prefer the way Linus has dealed with this 
lately. Some people consider that ACls should be "NT-like" or 
"Novell-like". Sincerly I think the problem does not end here but surely 
I would use "Novell-like" ACLs among these two. They are more primitive, 
basic, but much more flexible for use.  And answer for 
99,999999999999999999% of my requirements. Really, some things should be 
kept simple...

> 
>> I do prefer
>> its relative "marginalisation" as this will force people to concentrate
>> their efforts in the specificities of the task. It is preferable to
>> figth incompatibilities rather than security breaches. When a security
>> tool becomes too broad for use and development, it will have a bigger
>> chance to be attacked, broken or bugged.  Setting C2 at the level of the
>> main kernel development will surely give ground to such danger.
> 
> 
> I do not find this argument at all compelling
> 
You see, i am not talking that C2 does not rule, it's bad or needs Dirol 
to have good looking. What I am trying to tell is that, making it a 
"main trend", may hinder security tasks for which the protocol was never 
supposed to solve, but which people think it may work... And sorry, I 
can't see security as a Coca-Cola can. I surely shoot the first that 
shows me such a thing... That was one of the reasons why I sent nearly 3 
years of professional experience with one little program into the 
recycle bin (and completely wiped the recycle-bin with all its 
infrastructure)...

Ektanoor

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