Message-ID: <44305515.2010407@novell.com>
Date: Mon Apr  3 00:09:49 2006
From: crispin at novell.com (Crispin Cowan)
Subject: Re: [SC-L] Re: [Owasp-dotnet] RE: 4 Questions:
 Latest IE vulnerability, 
 Firefox vs IE security, User vs Admin risk profile, and browsers coded in
 100% Managed Verifiable code

Dinis Cruz wrote:
> Jeff Williams wrote:  
>> I'm a huge fan of sandboxes, but Dinis is right, the market hasn't really
>> gotten there yet. No question that it would help if it was possible to run
>> complex software like a browser inside a sandbox that restricted its ability
>> to do bad things, even if there are vulnerabilities (or worse -- malicious
>> code) in them.      
> Absolutely, and do you see any other alternative? (or we should just
> continue to TRUST every bit of code that is executed in our computers?
> and TRUST every single developer/entity that had access to that code
> during its development and deployment?)
>   
This is exactly what AppArmor <http://en.opensuse.org/Apparmor> was
designed for: conveniently confining applications to only be able to do
what they need to do. Application's least privilege.

I am running this mail client (Thunderbird) from within a "sandbox" (we
call it a "profile"). I have attached this policy, which should be
pretty self-explanatory.

>> But, if you've ever tried to configure the Java security policy file, use
>> JAAS, or implement the SecurityManager interface, you know that it's *way*
>> too hard to implement a tight policy this way.    
> And .Net has exactly the same problem. It is super complex to create a
> .Net application that can be executed in a secure Partially Trusted Sandbox.
>   
This is where AppArmor really stands out. You can build an application
profile in minutes. Here is a video
<ftp://ftp.belnet.be/pub/mirror/FOSDEM/FOSDEM2006-apparmor.avi> if me
demoing AppArmor in a presentation at FOSDEM 2006
<http://www.fosdem.org/2006>. The video is an hour-long lecture on
AppArmor, and for the impatient, the demo is from 16:30 through 26:00.

>> And only the
>> developer of the software could reasonably attempt it, which is backwards,
>> because it's the *user* who really needs it right. 
>>     
> Yes, it is the user's responsibility (i.e. its IT Security and Server
> Admin staff) to define the secure environment (i.e the Sandbox) that 3rd
> party or internal-developed applications are allocated inside their data
> center,
>   
It is very feasible for a user, not a developer, to build an AppArmor
profile. Prior requirements for using AppArmor are:

    * know how to use bash
    * know how to use chmod
    * know how to run the application in question


>> It's possible that sandboxes are going the way of multilevel security (MLS).
>> A sort of ivory tower idea that's too complex to implement or use.     
> I don't agree that the problem is too complex. What we have today is
> very complex architectures / systems with too many interconnections.
>   
"too many interconnections" is a Windows problem. In the UNIX world,
where (nearly) everything is a file, it is much easier to build
effective application containment policies.

> Simplify the lot, get enough resources with the correct focus involved,
> are you will see that it is doable.
>   
Indeed :)

> Basically, give the user data (as in information) that he can digest and
> understand, and you will see the user(s) making the correct decision(s).
>   
Well, maybe. Users are notorious for not making the right decision.
AppArmor lets the site admin create the policy and distribute it to
users. Of course that assumes we are talking about Linux users :)

Crispin
-- 
Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: opt.MozillaThunderbird.lib.thunderbird-bin
Url: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20060402/00b63c34/opt.MozillaThunderbird.lib.ksh

Powered by blists - more mailing lists