lkml.org 
[lkml]   [2007]   [Apr]   [19]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: AppArmor FAQ
    FromStephen Smalley <>
    DateThu, 19 Apr 2007 13:56:59 -0400
    On Tue, 2007-04-17 at 16:09 -0700, Crispin Cowan wrote:
    > David Safford wrote:
    > > On Mon, 2007-04-16 at 20:20 -0400, James Morris wrote:
    > > 
    > >> On Mon, 16 Apr 2007, John Johansen wrote:
    > >> 
    > >>> Label-based security (exemplified by SELinux, and its predecessors in
    > >>> MLS systems) attaches security policy to the data. As the data flows
    > >>> through the system, the label sticks to the data, and so security
    > >>> policy with respect to this data stays intact. This is a good approach
    > >>> for ensuring secrecy, the kind of problem that intelligence agencies have.
    > >>> 
    > >> Labels are also a good approach for ensuring integrity, which is one of 
    > >> the most fundamental aspects of the security model implemented by SELinux.  
    > >>
    > >> Some may infer otherwise from your document.
    > >> 
    > > In fact, I am not sure how you can provide integrity support without
    > > labels. AppArmor confines a process, but does not effectively confine 
    > > its output files, precisely because the output files are not labeled. 
    > > Other processes are free to access the unlabeled, potentially malicious 
    > > output files without restriction. 
    > > 
    > That depends on what you mean by "integrity." It is true that AppArmor
    > does not directly manage information flow. AppArmor assumes that if you
    > granted write permission to /etc/resolv.conf, that you meant to do that.
    > Whether any other process is permitted to access /etc/resolv.conf is
    > determined by those other process's respective profiles.
    
    Integrity protection requires information flow control; you can't
    protect a high integrity process from being corrupted by a low integrity
    process if you don't control the flow of information.  Plenty of attacks
    take the form of a untrusted process injecting data that will ultimately
    be used by a more trusted process with a surprising side effect.
    
    And you can't do information flow control if you can't provide global
    and persistent protection of the data, which requires labeling it and
    preserving that label for its lifetime.
    
    > What AppArmor provides is a way for administrators to confine software
    > that they have to run but do not trust. The use of pathnames means that
    > the administrator can understand the exact meaning of the security
    > policy, without having to do a complete labeling of the file system. The
    > flip side of not managing information flow is that each profile is
    > independent of every other profile.
    
    They aren't truly independent; the composition may lead to surprising
    results where each individual program is "confined" exactly as you
    specified, but in combination, one is able to corrupt the higher
    integrity subject by actions taken by the lower integrity subject.
    Particularly in the fun area of publically writable directories, where
    pathnames are largely useless as an indicator.
    
    -- 
    Stephen Smalley
    National Security Agency
    
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at  http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at  http://www.tux.org/lkml/
    
    
    \
     
     \ /
      Last update: 2007-04-19 19:59    [from the cache]
    ©2003-2008