full-disclosure - 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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <44334EAB.2000809@novell.com>
Date: Thu Apr  6 03:45:57 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

Pascal Meunier wrote:
> AppArmor sounds like an excellent alternative to creating a VMWare image for
> every application you want to run but distrust, although I can think of
> cases where a VMWare image would be safer.  For example, the
> installer/uninstaller may have vulnerabilities, may be "dirty" (it causes
> problems by modifying things that affect other applications, or doesn't
> cleanup correctly), or phones home, etc...  I guess you could make a profile
> for the installer as well (I'm not very enthusiastic about that idea
> though).  Also, I suspect that what you need to allow in some profiles is
> possibly sufficient to enable "some level" of malicious activity.  It's
> regrettable that it is only available for Suse Linux.
>   
That is correct. AppArmor is not a virtualization layer, and cannot be
used to create virtual copies of files for maybe-good/maybe-bad software
to mess with. More over, the LSM interface in the kernel (which both
AppArmor and SELinux depend on) is also not capable of virtualization.
There were requests for virtualization features during the LSM design
phase, but we decided that we wanted to keep LSM as unintrusive as
possible so as to maximize the chance of LSM being accepted by the 
upstream kernel.

> Perhaps one of the AppArmor mailing lists would be more appropriate to ask
> this,
apparmor-dev cc'd

>  but as you posted an example profile with "capability setuid", I must
> admit I am curious as to why an email client needs that.
Well now that is a very good question, but it has nothing to do with
AppArmor. The AppArmor learning mode just records the actions that the
application performs. With or without AppArmor, the Thunderbird mail
client is using cap_setuid. AppArmor gives you the opportunity to *deny*
that capability, so you can try blocking it and find out. But for
documentation on why Thunderbird needs it, you would have to look at
mozilla.org not the AppArmor pages.

>   I tried looking up
> relevant documentation on the Novell site, but it seems I was unlucky and
> tried during a maintenance period because pages were loading erratically.  I
> finally got to the "3.0 Building Novell AppArmor Profiles" page but it was
> empty.  I would appreciate receiving more information about it.  I am also
> interested in the "Linux Security Modules Interface".
>   
For an overview, look here:

    "Linux Security Modules: General Security Support for the Linux
    Kernel". Chris Wright, Crispin Cowan, Stephen Smalley, James Morris,
    and Greg Kroah-Hartman. Presented at the 11^th USENIX Security
    Symposium <http://www.usenix.org/events/sec02/>, San Francisco, CA,
    August 2002. PDF <http://crispincowan.com/%7Ecrispin/lsm-usenix02.pdf>.

However, this paper is only a general overview, and is now far out of
date. For an accurate view, look at the kernel source code.

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