From: Greg KH <greg@kroah.com>
To: Crispin Cowan <crispin@novell.com>
Cc: Andreas Gruenbacher <agruen@suse.de>,
Stephen Smalley <sds@tycho.nsa.gov>, Pavel Machek <pavel@ucw.cz>,
jjohansen@suse.de, linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org,
linux-fsdevel@vger.kernel.org
Subject: Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
Date: Fri, 15 Jun 2007 09:50:54 -0700 [thread overview]
Message-ID: <20070615165054.GA11345@kroah.com> (raw)
In-Reply-To: <466C303E.5010304@novell.com>
On Sun, Jun 10, 2007 at 10:09:18AM -0700, Crispin Cowan wrote:
> 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.
A daemon using inotify can "instantly"[1] detect this and label the file
properly if it shows up.
> * 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.
Same daemon can do the re-label.
> * 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.
Same daemon can do this. And yes, it might take a ammount of time, but
the times that this happens in "real-life" on a "production" server is
quite small, if at all.
> * 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.
Again, same daemon can handle this logic.
> * 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.
SELinux already provides support for the whole mounted filesystem,
which, in real-life testing, seems to be quite sufficient. Also, the
SELinux developers are working on some changes to make this a bit more
fine-grained.
See also Stephan's previous comments about NFSv3 client directories and
multiple views having the potential to cause a lot of havoc.
> You could support all of these features in SELinux, but only by adding
> an in-kernel file matching mechanism similar to AppArmor.
I don't think that is necessary at all, see above for why.
> 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.
No, do the labeling in userspace with a daemon using inotify to handle
the changing of the files around.
Or has this whole idea of a daemon been disproved already with a
prototype somewhere that failed? If not, a simple test app would not be
that hard to hack up. Maybe I'll see if I can do it during the week of
June 24 :)
thanks,
greg k-h
next prev parent reply other threads:[~2007-06-15 17:03 UTC|newest]
Thread overview: 240+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-14 11:06 [AppArmor 00/45] AppArmor security module overview jjohansen
2007-05-14 11:06 ` [AppArmor 01/45] Pass struct vfsmount to the inode_create LSM hook jjohansen
2007-05-14 11:06 ` [AppArmor 02/45] Pass struct path down to remove_suid and children jjohansen
2007-05-14 11:06 ` [AppArmor 03/45] Add a vfsmount parameter to notify_change() jjohansen
2007-05-14 11:06 ` [AppArmor 04/45] Pass struct vfsmount to the inode_setattr LSM hook jjohansen
2007-05-14 11:06 ` [AppArmor 05/45] Add struct vfsmount parameter to vfs_mkdir() jjohansen
2007-05-14 11:06 ` [AppArmor 06/45] Pass struct vfsmount to the inode_mkdir LSM hook jjohansen
2007-05-14 11:06 ` [AppArmor 07/45] Add a struct vfsmount parameter to vfs_mknod() jjohansen
2007-05-14 11:06 ` [AppArmor 08/45] Pass struct vfsmount to the inode_mknod LSM hook jjohansen
2007-05-14 11:06 ` [AppArmor 09/45] Add a struct vfsmount parameter to vfs_symlink() jjohansen
2007-05-14 11:06 ` [AppArmor 10/45] Pass struct vfsmount to the inode_symlink LSM hook jjohansen
2007-05-14 11:06 ` [AppArmor 11/45] Pass struct vfsmount to the inode_readlink " jjohansen
2007-05-14 11:06 ` [AppArmor 12/45] Add struct vfsmount parameters to vfs_link() jjohansen
2007-05-14 11:06 ` [AppArmor 13/45] Pass the struct vfsmounts to the inode_link LSM hook jjohansen
2007-05-14 11:06 ` [AppArmor 14/45] Add a struct vfsmount parameter to vfs_rmdir() jjohansen
2007-05-14 11:06 ` [AppArmor 15/45] Pass struct vfsmount to the inode_rmdir LSM hook jjohansen
2007-05-14 11:06 ` [AppArmor 16/45] Call lsm hook before unhashing dentry in vfs_rmdir() jjohansen
2007-05-14 11:06 ` [AppArmor 17/45] Add a struct vfsmount parameter to vfs_unlink() jjohansen
2007-05-14 11:06 ` [AppArmor 18/45] Pass struct vfsmount to the inode_unlink LSM hook jjohansen
2007-05-14 11:06 ` [AppArmor 19/45] Add struct vfsmount parameters to vfs_rename() jjohansen
2007-05-14 11:06 ` [AppArmor 20/45] Pass struct vfsmount to the inode_rename LSM hook jjohansen
2007-05-14 11:06 ` [AppArmor 21/45] Add a struct vfsmount parameter to vfs_setxattr() jjohansen
2007-05-14 11:06 ` [AppArmor 22/45] Pass struct vfsmount to the inode_setxattr LSM hook jjohansen
2007-05-14 11:06 ` [AppArmor 23/45] Add a struct vfsmount parameter to vfs_getxattr() jjohansen
2007-05-14 11:06 ` [AppArmor 24/45] Pass struct vfsmount to the inode_getxattr LSM hook jjohansen
2007-05-14 11:06 ` [AppArmor 25/45] Add a struct vfsmount parameter to vfs_listxattr() jjohansen
2007-05-14 11:06 ` [AppArmor 26/45] Pass struct vfsmount to the inode_listxattr LSM hook jjohansen
2007-05-14 11:06 ` [AppArmor 27/45] Add a struct vfsmount parameter to vfs_removexattr() jjohansen
2007-05-14 11:06 ` [AppArmor 28/45] Pass struct vfsmount to the inode_removexattr LSM hook jjohansen
2007-05-14 11:06 ` [AppArmor 29/45] Fix __d_path() for lazy unmounts and make it unambiguous jjohansen
2007-05-14 11:06 ` [AppArmor 30/45] Make d_path() consistent across mount operations jjohansen
2007-05-14 11:06 ` [AppArmor 31/45] Add d_namespace_path() to compute namespace relative pathnames jjohansen
2007-05-14 11:06 ` [AppArmor 32/45] Enable LSM hooks to distinguish operations on file descriptors from operations on pathnames jjohansen
2007-05-14 11:06 ` [AppArmor 33/45] Pass struct file down the inode_*xattr security LSM hooks jjohansen
2007-05-14 11:06 ` [AppArmor 34/45] Factor out sysctl pathname code jjohansen
2007-05-14 11:06 ` [AppArmor 35/45] Allow permission functions to tell between parent and leaf checks jjohansen
2007-05-15 9:08 ` Pavel Machek
2007-05-14 11:06 ` [AppArmor 36/45] Export audit subsystem for use by modules jjohansen
2007-05-14 11:06 ` [AppArmor 37/45] AppArmor: Main Part jjohansen
2007-05-15 9:12 ` Pavel Machek
2007-05-14 11:06 ` [AppArmor 38/45] AppArmor: Module and LSM hooks jjohansen
2007-05-15 9:14 ` Pavel Machek
2007-05-23 16:16 ` Andreas Gruenbacher
2007-06-04 10:55 ` Pavel Machek
2007-06-04 11:25 ` Andreas Gruenbacher
2007-06-04 11:35 ` Pavel Machek
2007-06-04 11:42 ` Andreas Gruenbacher
2007-06-04 13:12 ` Pavel Machek
2007-06-04 14:30 ` Andreas Gruenbacher
2007-06-06 13:09 ` Stephen Smalley
2007-06-10 23:10 ` Andreas Gruenbacher
2007-06-11 14:33 ` Stephen Smalley
2007-06-11 15:55 ` Andreas Gruenbacher
2007-06-11 19:02 ` Serge E. Hallyn
2007-06-12 13:00 ` Stephen Smalley
2007-06-12 15:34 ` Serge E. Hallyn
2007-06-12 5:17 ` Karl MacMillan
2007-06-12 19:00 ` Serge E. Hallyn
2007-06-12 13:13 ` Stephen Smalley
2007-06-12 23:50 ` Andreas Gruenbacher
2007-06-09 12:58 ` Pavel Machek
2007-06-09 13:44 ` Andreas Gruenbacher
2007-06-12 13:06 ` Pavel Machek
2007-05-14 11:06 ` [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching jjohansen
2007-05-15 9:20 ` Pavel Machek
2007-06-04 21:03 ` Andreas Gruenbacher
2007-06-06 13:26 ` Stephen Smalley
2007-06-06 17:32 ` Greg KH
2007-06-09 23:47 ` Pavel Machek
2007-06-08 22:03 ` Andreas Gruenbacher
2007-06-09 0:17 ` Greg KH
2007-06-09 1:06 ` david
2007-06-09 2:01 ` [AppArmor 39/45] AppArmor: Profile loading and manipulation,pathname matching Tetsuo Handa
2007-06-09 3:25 ` Sean
2007-06-09 4:56 ` david
2007-06-09 5:10 ` Sean
2007-06-09 5:38 ` david
2007-06-09 5:44 ` Sean
2007-06-09 7:04 ` david
2007-06-09 7:28 ` Sean
2007-06-09 8:03 ` david
2007-06-09 8:37 ` Sean
2007-06-14 17:01 ` Pavel Machek
2007-06-09 11:26 ` [AppArmor 39/45] AppArmor: Profile loading andmanipulation,pathname matching Tetsuo Handa
2007-06-09 11:35 ` Sean
2007-06-09 13:41 ` david
2007-06-09 18:37 ` [AppArmor 39/45] AppArmor: Profile loading and manipulation,pathname matching Casey Schaufler
2007-06-15 13:36 ` Pavel Machek
2007-06-10 8:34 ` [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching Pavel Machek
2007-06-10 9:04 ` david
2007-06-10 20:04 ` Casey Schaufler
2007-06-10 20:51 ` Crispin Cowan
2007-06-11 6:45 ` david
2007-06-11 8:29 ` Sean
2007-06-11 9:33 ` david
2007-06-11 11:34 ` Sean
2007-06-11 11:00 ` Pavel Machek
2007-06-10 21:05 ` Pavel Machek
2007-06-11 6:27 ` david
2007-06-14 19:16 ` Jack Stone
2007-06-15 0:18 ` david
2007-06-15 17:01 ` Greg KH
2007-06-12 17:03 ` Lars Marowsky-Bree
2007-06-09 5:18 ` david
2007-06-09 5:46 ` Sean
2007-06-09 7:13 ` david
2007-06-09 7:36 ` Sean
2007-06-09 8:06 ` david
2007-06-09 8:10 ` Sean
2007-06-09 15:17 ` Andreas Gruenbacher
2007-06-09 16:36 ` Sean
2007-06-09 15:33 ` Joshua Brindle
2007-06-09 16:18 ` Kyle Moffett
2007-06-09 16:46 ` david
2007-06-09 17:06 ` Kyle Moffett
2007-06-09 17:32 ` david
2007-06-09 19:50 ` Kyle Moffett
2007-06-09 20:43 ` david
2007-06-10 20:54 ` Crispin Cowan
2007-06-10 21:17 ` Joshua Brindle
2007-06-09 15:05 ` Andreas Gruenbacher
2007-06-10 17:09 ` Crispin Cowan
2007-06-15 16:50 ` Greg KH [this message]
2007-06-15 18:01 ` Casey Schaufler
2007-06-15 18:15 ` Stephen Smalley
2007-06-15 20:43 ` Casey Schaufler
2007-06-15 21:14 ` Greg KH
2007-06-15 21:28 ` Karl MacMillan
2007-06-15 21:44 ` Greg KH
2007-06-15 22:24 ` Karl MacMillan
2007-06-18 13:33 ` Stephen Smalley
2007-06-21 15:54 ` Andreas Gruenbacher
2007-06-15 22:37 ` Casey Schaufler
2007-06-18 12:47 ` Stephen Smalley
2007-06-15 20:06 ` Pavel Machek
2007-06-15 21:11 ` Greg KH
2007-06-15 21:42 ` James Morris
2007-06-15 23:50 ` Greg KH
2007-06-16 1:21 ` James Morris
2007-06-16 2:57 ` Casey Schaufler
2007-06-16 3:39 ` James Morris
2007-06-18 1:51 ` Casey Schaufler
2007-06-18 11:29 ` Joshua Brindle
2007-06-16 4:23 ` Greg KH
2007-06-15 23:30 ` Crispin Cowan
2007-06-15 23:49 ` Greg KH
2007-06-16 0:01 ` david
2007-06-16 0:20 ` Pavel Machek
2007-06-22 9:59 ` Andreas Gruenbacher
2007-06-16 0:31 ` Greg KH
2007-06-16 8:09 ` david
2007-06-16 16:24 ` Greg KH
2007-06-16 1:41 ` James Morris
2007-06-16 0:18 ` Seth Arnold
2007-06-16 0:29 ` Greg KH
2007-06-16 1:46 ` James Morris
2007-06-16 2:19 ` James Morris
2007-06-18 18:48 ` Crispin Cowan
2007-06-21 16:01 ` Andreas Gruenbacher
2007-06-21 17:59 ` Pavel Machek
2007-06-16 0:02 ` Pavel Machek
2007-06-21 16:08 ` Lars Marowsky-Bree
2007-06-21 18:33 ` Pavel Machek
2007-06-21 19:24 ` Lars Marowsky-Bree
2007-06-21 19:42 ` James Morris
2007-06-21 19:54 ` Lars Marowsky-Bree
2007-06-21 20:59 ` Stephen Smalley
2007-06-21 21:17 ` Lars Marowsky-Bree
2007-06-22 0:16 ` Joshua Brindle
2007-06-22 0:19 ` Lars Marowsky-Bree
2007-06-22 0:28 ` david
2007-06-22 3:45 ` Joshua Brindle
2007-06-22 5:07 ` david
2007-06-22 10:49 ` Lars Marowsky-Bree
2007-06-22 11:19 ` Stephen Smalley
2007-06-22 11:34 ` Neil Brown
2007-06-22 11:48 ` Stephen Smalley
2007-06-22 11:37 ` Lars Marowsky-Bree
2007-06-22 12:41 ` Stephen Smalley
2007-06-22 12:54 ` Lars Marowsky-Bree
2007-06-22 13:22 ` Stephen Smalley
2007-06-22 14:49 ` Stephen Smalley
2007-06-22 16:06 ` Casey Schaufler
2007-06-22 0:34 ` Chris Mason
2007-06-22 1:06 ` James Morris
2007-06-22 4:17 ` Crispin Cowan
2007-06-22 12:20 ` Stephen Smalley
2007-06-24 20:45 ` David Wagner
2007-06-22 7:40 ` John Johansen
2007-06-22 12:17 ` Chris Mason
2007-06-22 13:48 ` James Morris
2007-06-22 14:02 ` Chris Mason
2007-06-22 14:23 ` James Morris
2007-06-22 17:30 ` Chris Mason
2007-06-23 0:11 ` Chris Wright
2007-06-24 0:10 ` Toshiharu Harada
2007-06-24 0:40 ` Toshiharu Harada
2007-06-26 21:01 ` Crispin Cowan
2007-06-24 20:43 ` Pavel Machek
2007-06-22 18:12 ` david
2007-06-25 15:14 ` Pavel Machek
2007-06-25 21:02 ` david
2007-06-26 8:50 ` Lars Marowsky-Bree
2007-06-24 21:16 ` David Wagner
2007-06-24 21:57 ` david
2007-06-28 18:13 ` Pavel Machek
2007-06-28 18:19 ` Pavel Machek
2007-06-24 21:45 ` David Wagner
2007-06-28 18:31 ` Pavel Machek
2007-06-24 21:20 ` David Wagner
2007-06-22 8:06 ` John Johansen
2007-06-22 11:53 ` Stephen Smalley
2007-06-22 12:42 ` Lars Marowsky-Bree
2007-06-22 12:46 ` Stephen Smalley
2007-06-22 18:35 ` david
2007-06-24 20:48 ` David Wagner
2007-06-24 20:35 ` David Wagner
2007-06-21 20:07 ` Pavel Machek
2007-06-21 20:21 ` Lars Marowsky-Bree
2007-06-21 23:25 ` John Johansen
2007-06-21 19:30 ` david
2007-06-21 19:35 ` Lars Marowsky-Bree
2007-06-21 19:52 ` Pavel Machek
2007-06-16 0:48 ` [AppArmor 39/45] AppArmor: Profile loading and manipulation,pathname matching Tetsuo Handa
2007-06-19 15:25 ` Pavel Machek
2007-06-15 23:33 ` [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching Seth Arnold
2007-06-15 23:39 ` Pavel Machek
2007-06-16 0:07 ` Seth Arnold
2007-06-16 15:44 ` [AppArmor 39/45] AppArmor: Profile loading and manipulation,pathname matching Tetsuo Handa
2007-06-16 16:26 ` Greg KH
2007-06-16 16:45 ` [AppArmor 39/45] AppArmor: Profile loading andmanipulation,pathname matching Tetsuo Handa
2007-06-11 15:16 ` [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching Stephen Smalley
2007-05-14 11:06 ` [AppArmor 40/45] AppArmor: all the rest jjohansen
2007-05-14 11:06 ` [AppArmor 41/45] Add AppArmor LSM to security/Makefile jjohansen
2007-05-14 11:06 ` [AppArmor 42/45] AppArmor: add lock subtyping so lockdep does not report false dependencies jjohansen
2007-05-14 11:06 ` [AppArmor 43/45] Switch to vfs_permission() in do_path_lookup() jjohansen
2007-05-14 11:06 ` [AppArmor 44/45] Switch to vfs_permission() in sys_fchdir() jjohansen
2007-05-14 11:06 ` [AppArmor 45/45] Fix file_permission() jjohansen
2007-05-14 13:50 ` [AppArmor 00/45] AppArmor security module overview John Johansen
2007-10-26 6:40 jjohansen
2007-10-26 6:41 ` [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching jjohansen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070615165054.GA11345@kroah.com \
--to=greg@kroah.com \
--cc=agruen@suse.de \
--cc=crispin@novell.com \
--cc=jjohansen@suse.de \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=sds@tycho.nsa.gov \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).