Home page logo
/

fulldisclosure logo Full Disclosure mailing list archives

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
From: Crispin Cowan <crispin () novell com>
Date: Sun, 02 Apr 2006 15:49:57 -0700

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

# vim:syntax=subdomain
# Last Modified: Sun Apr  2 15:09:49 2006
/opt/MozillaThunderbird/lib/thunderbird-bin {
  #include <abstractions/X>
  #include <abstractions/base>
  #include <abstractions/bash>
  #include <abstractions/consoles>
  #include <abstractions/fonts>
  #include <abstractions/gnome>
  #include <abstractions/kde>
  #include <abstractions/nameservice>
  #include <abstractions/perl>
  #include <abstractions/user-mail>
  #include <abstractions/user-tmp>

  capability ipc_lock,
  capability setuid,

  /bin/basename px,
  /bin/bash ix,
  /bin/grep ixr,
  /bin/netstat px,
  /etc/mailcap r,
  /etc/mime.types r,
  /etc/opt/gnome/gnome-vfs-2.0/modules r,
  /etc/opt/gnome/gnome-vfs-2.0/modules/* r,
  /etc/opt/gnome/pango/pango.modules r,
  /home/** rw,
  /home/*/.gnupg/* lrw,
  /home/*/.thunderbird/** lrw,
  /opt/MozillaFirefox/bin/firefox.sh pxr,
  /opt/MozillaFirefox/lib/mozilla-xremote-client ixr,
  /opt/MozillaThunderbird/lib/** r,
  /opt/gnome/bin/file-roller ixr,
  /opt/gnome/bin/gedit ixr,
  /opt/gnome/bin/gimp-remote-2.2 ixr,
  /usr/X11R6/bin/OOo-wrapper px,
  /usr/X11R6/bin/acroread px,
  /usr/X11R6/bin/xv px,
  /usr/X11R6/lib/Acrobat7/Resource/Font/** r,
  /usr/bin/display px,
  /usr/bin/gpg ix,
  /usr/bin/mplayer px,
  /usr/bin/ooo-wrapper ixr,
  /usr/bin/perl ix,
  /usr/lib/firefox/firefox.sh px,
  /usr/lib/jvm/java-1.4.2-sun-1.4.2.06/jre/lib/fonts/** r,
  /usr/lib/ooo-2.0/program/soffice px,
  /usr/lib/ooo-2.0/share/fonts/** r,
}
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault