linux-kernel - Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching

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]

Date:	Sun, 10 Jun 2007 10:09:18 -0700
From:	Crispin Cowan <crispin@...ell.com>
To:	Andreas Gruenbacher <agruen@...e.de>
CC:	Greg KH <greg@...ah.com>, Stephen Smalley <sds@...ho.nsa.gov>,
	Pavel Machek <pavel@....cz>, jjohansen@...e.de,
	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	linux-fsdevel@...r.kernel.org
Subject: Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation,
 pathname matching

Andreas Gruenbacher wrote:
> On Saturday 09 June 2007 02:17, Greg KH wrote:
>   
>> On Sat, Jun 09, 2007 at 12:03:57AM +0200, Andreas Gruenbacher wrote:
>>     
>>> AppArmor is meant to be relatively easy to understand, manage, and
>>>  customize, and introducing a labels layer wouldn't help these goals.
>>>       
>> Woah, that describes the userspace side of AA just fine, it means
>> nothing when it comes to the in-kernel implementation. There is no 
>> reason that you can't implement the same functionality using some
>> totally different in-kernel solution if possible.
>>     
> I agree that the in-kernel implementation could use different abstractions 
> than user-space, provided that the underlying implementation details can be 
> hidden well enough. The key phrase here is "if possible", and in fact "if 
> possible" is much too strong: very many things in software are possible, 
> including user-space drives and a stable kernel module ABI. Some things make 
> sense; others are genuinely bad ideas while still possible.
>   
In particular, to layer AppArmor on top of SELinux, the following
problems must be addressed:

    * New files: when a file is created, it is labeled according to the
      type of the creating process and the type of the parent directory.
      Applications can also use libselinux to use application logic to
      relabel the file, but that is not 'mandatory' policy, and fails in
      cases like cp and mv. AppArmor lets you create a policy that e..g
      says "/home/*/.plan r" to permit fingerd to read everyone's .plan
      file, should it ever exist, and you cannot emulate that with SELinux.
    * Renamed Files: Renaming a file changes the policy with respect to
      that file in AA. To emulate this in SELinux, you would have to
      have a way to instantly re-label the file upon rename.
    * Renamed Directory trees: The above problem is compounded with
      directory trees. Changing the name at the top of a large, bushy
      tree can require instant relabeling of millions of files.
    * New Policies: The SEEdit approach of compiling AA profiles into
      SELinux labels involves computing the partition set of files, so
      that each element of the partition set is unique, and corresponds
      to all the policies that treat every file in the element
      identically. If you create a new profile that touches *some* of
      the files in such an element, then you have to split that
      synthetic label, re-compute the partition set, and re-label the
      file system.
    * File Systems That Do Not Support Labels: The most important being
      NFS3 and FAT. Because they do not support labels at all, SELinux
      has to give you an all-or-nothing access control on the entire
      remote volume. AA can give you nuanced access control in these
      file systems.

You could support all of these features in SELinux, but only by adding
an in-kernel file matching mechanism similar to AppArmor. It would
basically load an AppArmor policy into the kernel, label files as they
are brought from disk into the cache, and then use SELinux to do the
access controls.

That doesn't make it a good idea:

    * The patch would be at least as complex and intrusive as the
      proposed AppArmor patch, there is no simplicity already-upstream
      savings here.
    * It would require the VFS and d_path patches that AppArmor needs to
      pass mount points down.
    * It would make AppArmor's ability to change policies on a live
      system more difficult.
    * The necessary extensions would not be appealing to the SELinux
      community.

LSM is the common code that AA and SELinux have agreed to be mutually
useful. Forcing AA to sit on top of SELinux would harm both AA and SELinux.

Crispin

-- 
Crispin Cowan, Ph.D.               http://crispincowan.com/~crispin/
Director of Software Engineering   http://novell.com
	AppArmor Chat: irc.oftc.net/#apparmor

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/