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

[Rodrigo Rubira Branco (BSDaemon)]

Steve,

When you have "security professionals" writting the default behavior you
don't have the specific needs and the custom applications involved, and then
the problem of turn everything ok begin...

In the pratice, many people (mostly?) just disable selinux in the
installation process...

Like you have said, both have bad points (attack vectors...) but I think
complexity != security, so, im in favour of the auto-learning systems..


cya,


Rodrigo (BSDaemon).

--
http://www.kernelhacking.com/rodrigo

Kernel Hacking: If i really know, i can hack

GPG KeyID: 5E90CA19


--------- Mensagem Original --------
De: Steve Grubb <sgrubb at redhat.com>
Para: dailydave at lists.immunitysec.com <dailydave at lists.immunitysec.com>,
Rodrigo Rubira Branco BSDaemon <rodrigo at kernelhacking.com>
Assunto: Re: [Dailydave] Is Windows Integrity Control in Vista really worth
the performance hit? And does it really work?
Data: 02/03/07 11:27

>
> On Thursday 01 March 2007 14:12:41 Rodrigo Rubira Branco (BSDaemon) wrote:
> &gt; &gt; We got eal4+ without SE Linux as part of the eval.
> &gt;
> &gt; Yeah, it depends of the TE of the certification, the new level and TE
is
> &gt; really dependent of selinux... in any way i have said about eal4+
just
> &gt; because i seen in this link
> &gt; 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.
>
> &gt; &gt; &amp;gt; using the LSM framework... its more bugged than great
(who don´t
> &gt; agree with me??).
> &gt;
> &gt; &gt; I don't agree with you. I don't have any bug report in our
bugzilla that
> &gt; &gt; is traced to the kernel implementation.
> &gt;
> &gt; Its a design error, not necessarily implementation one... because
that we
> &gt; 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.
>
> &gt; in any way I wanna know your opinion about another point that is
> &gt; learning-mode systems... i have a discussion about that with Joshua
in the
> &gt; 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
>
>
>
>
>
>

________________________________________________
Message sent using UebiMiau 2.7.2