[Dailydave] Is Windows Integrity Control in Vista really worth the performance hit? And does it really work?

[Steve Grubb]

On Thursday 01 March 2007 14:12:41 Rodrigo Rubira Branco (BSDaemon) wrote:
> > We got eal4+ without SE Linux as part of the eval.
>
> Yeah, it depends of the TE of the certification, the new level and TE is
> really dependent of selinux... in any way i have said about eal4+ just
> because i seen in this link
> http://www.internetnews.com/security/article.php/3551616

When you talk about a certification, there are 2 parts to it. That article 
talks about our current effort which is LSPP/EAL4+. LSPP is the feature 
selection, which selinux is needed for the MAC portions of the security 
target. EAL4+ simply refers to the level of effort that went into design, 
documentation, and testing. SE Linux by itself does not meet LSPP, there was 
a whole lot of other work needed, too.

> > > using the LSM framework... its more bugged than great (who don´t
> agree with me??).
>
> > I don't agree with you. I don't have any bug report in our bugzilla that
> > is traced to the kernel implementation.
>
> Its a design error, not necessarily implementation one... because that we
> see lots of discussion regarding how to remove it ;)

I haven't been involved in any discussions where people are asking to remove 
it. I have been involved in discussions where people believe they have 
sufficient protection in place where they want to disable it for performance.

> in any way I wanna know your opinion about another point that is
> learning-mode systems... i have a discussion about that with Joshua in the
> past, but no conclusions... 

I can only guess that you mean systems that learn normal behavior so that 
abnormalities can be spotted? The problem is how do you _know_ you are 
observing correct behavior. You could have a trojaned app that you are now 
learning its behavior. 

You can imagine SE Linux policy as a learning mode system where _people_ learn 
the app's behavior. They exercise the app, determine its normal behavior, put 
that into policy, and people everywhere install it.

Then one day we get a new version of something and push it into rawhide. 
Suddenly we have AVCs (syscall denials based on policy). The behavior has 
changed. Is it a trojaned app or correct but new behavior? Does anyone have a 
program that can make that determination?

It would take a human in the loop, either by asking the user if this is 
expected behavior - which they probably can't determine the implications of 
allowing the action (there are knowledgeable people out there, but we can't 
assume everyone is a programmer/admin). Or it takes skilled policy writers to 
make the decision and add it to policy - learning the new behavior. So, you 
always have this problem of version upgrades and learning new behavior. That 
can become the attack point.

-Steve