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]

Message-Id: <20070611042919.8feffc40.seanlkml@sympatico.ca>
Date:	Mon, 11 Jun 2007 04:29:19 -0400
From:	Sean <seanlkml@...patico.ca>
To:	david@...g.hm
Cc:	Crispin Cowan <crispin@...ell.com>, casey@...aufler-ca.com,
	Pavel Machek <pavel@....cz>, Greg KH <greg@...ah.com>,
	Andreas Gruenbacher <agruen@...e.de>,
	Stephen Smalley <sds@...ho.nsa.gov>, 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

On Sun, 10 Jun 2007 23:45:16 -0700 (PDT)
david@...g.hm wrote:

> say that we give each file a unique label, and for simplicity we set the 
> label == path (note that this raises the issue, what will SELinux do when 
> there are multiple paths to the same file)

So don't do that then.

> now say that you want to grant apache access to all files that have labels 
> that follow the pattern '/home/*/http/* ?
> 
> you are either going to use regex matching, or you are going to have to 
> enumerate every label that matches this (potentially a very large list). 
> and if you try to generate the enumerated list you need to add a label to 
> the list if a file is renamed or created to match the pattern, and delete 
> a file from the list if it is renamed to no longer match the pattern

If AA requires regex matching in the kernel, perhaps it really isn't
appropriate for inclusion.  Surely there has to be a better way than
requiring the kernel to do regex matches at runtime?

> AA over SELinux would need for SELinux to figure out how to handle file 
> creation, file renames, and multiple paths for the same file (hard-links 
> and bind-mounts). In addition a userspace daemon would have to be written 
> to re-label files and/or change policy on the fly as files are renamed. 
> the result would still have race conditions due to the need to re-label 
> large numbers of files

WRONG.  The labels would be obtained from AA as needed, never recorded in
the file attributes.  This would change nothing about what AA needed
to compute at runtime, just the way it implements the result.

> ACPI should have taught everyone that sometimes putting an interpreter in 
> the kernel really is the best option. looking at the problems of bouncing 
> back out to userspace for file creation and renames it looks like a regex 
> in the kernel is a lot safer and more reliable.

There hasn't yet been shown a requirement for a userspace daemon to implement
AA over SeLinux.

Sean
-
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/