Re: C2 vs Common Criteria [was: RE: Is this mail list dead?]

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

LA Walsh wrote:

> Pedro Rosa wrote:
> 
> 
> 	Take a look at the Common Criteria CAPP definition mentioned in
> an earlier post.  On a CAPP-level trusted system, I think you can get
> by with plaintext password storage in /etc/shadow (still only readable by
> root).  

Well I will surely study the CAPP but I believe the criteria you present 
as an example is flawed. The way you present this gives the system a 
status of being in the edge of Nothing. Note that many popular distros 
forget to give a propper and secured booting sequence. Some situations 
when you break this sequence may send you right into the shell with all 
privileges. That's very bad. But it will be horrible if such thing as 
shadow will be clear readable. The next boot, the cracker will not need 
anything more than just wipe his activities from the logs, which a 
professional will easily do.

Now talking about C2's, CAPP's and similars. Your example is _exactly_ 
what I'm afraid of. Ok, we set a few "silver" and "gold" security 
mechanisms into the kernel. We may also add a "platinum" service. 
However implementations remain on the level of such silly things like 
your example or mine. What should a user expect? To have another Windows 
marvel roaming around? "Oh it's there but it's still not there but it 
surely will be there"... "No, no, no, it's not a bug or a feature or 
anomaly. It's the weather."

Ok you may say that we the experts are here and exist to solve these 
problems. But what do you prefer? A clean road without rocks or 
thousands of angry users that feel someone played a very bad joke on 
them? Giving an illusion of security will give birth to the second case. 
For sure. And even the implementation of a primitive and simple C2 will 
surely give ground to such a thing. There is already a clear and very 
sad example of such illusion and its consequences. Well I think everyone 
knows who I'm referring about.  I will only denote that my ideas don't 
come from IT magazines and coffee mug talks but from a few serious 
incidents with "C2 compatibilities". And one such case had me trying to 
do the dirty job of implementing C2 rules into one machine. This failed 
miserably because the architecture of the system was completely flawed.

> 
> 
> 	Secure = I've made my system a complex enough puzzle put off most
> people.  Trusted = evaluated assertions of levels of trust of a given

As another poster referred, this is "security through obscurity". Which 
is not security at all. In fact such approach needs only a non-standard 
and original mind to break in. Are they hard to find? No. Any guy with a 
"Holmes" intuition about the inners of the OS and the machine will be 
able to do it in minutes. I once saw how such minds break physical keys 
in tens of seconds just as they know "see" Assembler as we see this text 
(there was one case on which the break took less than 15 seconds, I give 
all guarantees that the cracker saw that program for the very first 
time). And these cases were exactly due to the fact that the original 
programmers approached the security problem through the point of 
"security through obscurity". 

Security should be established in straightforward protocols. One should 
pass through different steps to get the authorization to use the 
resources. And here, these steps should be more than just puzzles. One 
cannot allow systems calls or other things to be processed during login, 
one should encage different functions inside buffer limits that cannot 
be overpassed. Well it is a whole complex system. C2 is exactly one of 
the answers to this. But I cannot consider its implementation without 
looking at the building in the whole. I cannot speak about the 
implementation before I see what the user needs. I cannot see C2 in the 
kernel while many other things will only give it a status of "security 
through obscurity". This is a highly complex question to be just 
discussed in a "to be or not to be" mood...

Frankly I would first look at other side of the question. I would study 
first users needs. Get a picture of the damn dirty world we live in. I 
would systematize this worldwide swamp. Then I would start discussing 
approaches and maybe choose solutions. Maybe some of them would be too 
good so they could be implemented in the kernel. Maybe. But there is a 
concept I believe that tells me to avoid broad approaches - "Security 
should be private". 

Ok we have a few glimpses of what users may need or not. The 
broad/family-scale user will surely need a minimalistic and simple 
security scheme. Enough to avoid some types of intrusions like trojans 
or worms. Some of these users may even cry for the removal of 
traditional security mechanisms (should we consider them, I think we 
should even if it is to consider they are lamers).

Now we have middle-level users that may require a term between 
traditional *NIX and such things like C2. In any case they will highly 
require that the simplistic mechanisms will be secure enough to the 
level they are supposed to answer. In the mean time some may consider 
such security is not enough and require something stronger. Here I would 
not put "protocols" or "standards" in first place. These users are 
sometimes quite complex in their requirements. They may require that you 
build a stronghold in one section of the system and leave everything 
else untouched or even weakened. Yes, some experts may say "heresy!". 
But these cases are frequently met not inside one computer but all over 
one office, with rooms, doors, air conducts and people of different 
kinds. While some requirements are based on stupid lamerism, others are 
the complete mirror image of these. One may note that there are two 
kinds of companies that are hard to deal with: those where economists 
rule and those where engineers rule. Economists are the lamb herd. 
Stubborn, strightminded and thinking they know the world (well not all 
of them). Engineers are the wolfpack. They know who you are, they know 
what you do, they may even be from the same jungle you came from, and 
they have a good general knowledge about what a computer is or can be. 
The lambs may put very hard tasks to solve from the theoretical point of 
view (frequently they play the Mission Impossible). Wolves on the 
contrary would like to have that, that, that and that but stop on 
setting that. With the first group one should think not only on how to 
secure things from outside attacks but also how to avoid the inside 
lamers. With the second group general tasks will be easier but sometimes 
requirements are so damn specific that you take in one single task much 
more time then usual.  

Now we have the corporate users. But here they will need C2 and there 
are a lot of corporate fans here. But do they need it? Well, for some, I 
DON'T THINK SO... But let's think why...



> 
> 
PS: Ok people I'm just trying to see if this "Is this mail list dead" 
question gets well dead...

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