Re: [RFC 0/28] Patches to pass vfsmount to LSM inode security hooks

On Monday 05 February 2007 11:50, Chris Wright wrote: This kind of change (or perhaps straight to struct path) is definitely needed from AA. I tried struct path; in terms of code size it doesn't seem worth it. We could get identical code out of it as if we were passing the dentry and vfsmount

Re: [RFC 0/28] Patches to pass vfsmount to LSM inode security hooks

On Monday 05 February 2007 11:02, Christoph Hellwig wrote: On Mon, Feb 05, 2007 at 10:58:26AM -0800, Trond Myklebust wrote: On Mon, 2007-02-05 at 18:44 +, Christoph Hellwig wrote: Just FYI: Al was very opposed to the idea of passing the vfsmount to the vfs_ helpers, so you should

Re: [AppArmor 37/41] AppArmor: Main Part

On Thursday 12 April 2007 12:37, Alan Cox wrote: The proc file system may not be mounted at /proc. There are environments where this is done for good reason (eg not wanting the /proc info exposed to a low trust environment). Another is when FUSE is providing an arbitrated proc either by

Re: [nameidata 1/2] Don't pass NULL nameidata to vfs_create

On Monday 16 April 2007 18:21, Christoph Hellwig wrote: But anyway, creating fake nameidata structures is not really helpful. If there is a nameidata passed people expect it to be complete, and if you pass them to an LSM people will e.g. try to look into lookup intents. I don't actually agree

Re: [nameidata 2/2] Pass no useless nameidata to the create, lookup, and permission IOPs

On Monday 16 April 2007 18:42, Randy Dunlap wrote: Please don't use the kernel-doc begin-marker /** when the comment block isn't in kernel-doc format. Sigh, kernel-doc should improve things, not get in the way ... - To unsubscribe from this list: send the line unsubscribe linux-security-module

Re: [AppArmor 31/41] Fix __d_path() for lazy unmounts and make it unambiguous; exclude unreachable mount points from /proc/mounts

On Monday 16 April 2007 23:57, Alan Cox wrote: I don't believe the existing behaviour _IS_ a mistake. So what would be the arguments why this behavior makes sense, other than legacy? For /proc/mounts, one could argue that the admin might want to see everything, but then that's not actually

[d_path 1/7] Fix __d_path() for lazy unmounts and make it unambiguous

from /proc/mounts. Signed-off-by: Andreas Gruenbacher [EMAIL PROTECTED] --- fs/dcache.c | 169 ++-- 1 file changed, 98 insertions(+), 71 deletions(-) --- a/fs/dcache.c +++ b/fs/dcache.c @@ -1732,52 +1732,51 @@ shouldnt_be_hashed

[d_path 0/7] Fixes to d_path: Respin

On Tuesday 17 April 2007 19:21, Alan Cox wrote: Can you prove no existing application on the planet relies on the existing behaviour ? Actually more limited but sane as a test would be Can you prove that the glibc behaviour visible to applications does not change As far as I can see, glibc

Re: [d_path 0/7] Fixes to d_path: Respin

On Friday 20 April 2007 17:15, Ulrich Drepper wrote: On 4/20/07, Andreas Gruenbacher [EMAIL PROTECTED] wrote: Possibly for fstatfs(): fstatfs() has no way of looking up mount points per path name in /proc/mounts, and so it resorts to mapping from the numeric statfs-f_type to the filesystem

Re: [d_path 3/7] Add d_namespace_path() to compute namespace relative pathnames

On Saturday 21 April 2007 14:57, Tetsuo Handa wrote: So, you may want customized version of d_namespace_path()? No. d_namespace_path() returns valid pathnames, just like d_path() does. Whatever quoting needed can be added to the resulting pathname. Andreas - To unsubscribe from this list: send

Re: [d_path 0/7] Fixes to d_path: Respin

On Friday 20 April 2007 21:17, Ulrich Drepper wrote: On 4/20/07, Andreas Gruenbacher [EMAIL PROTECTED] wrote: The code also seems to stop at the first matching mount point. You can have the same device mounted on the same mount point multiple times but with different mount options, e.g

Re: [d_path 0/7] Fixes to d_path: Respin

On Sunday 22 April 2007 11:10, Christoph Hellwig wrote: So what about stopping the flaming here and implementing real statvfs/ fstatvfs syscalls instead of these horrible hacks glibc has to do currently? I could imagine two approaches to that: either add statvfs and fstatvfs syscalls, or use

Re: [AppArmor 38/45] AppArmor: Module and LSM hooks

On Tuesday 15 May 2007 11:14, Pavel Machek wrote: Why is this configurable? The maximum length of a pathname is an arbitrary limit: we don't want to allocate arbitrary amounts of of kernel memory for pathnames so we introduce this limit and set it to a reasonable value. In the unlikely case

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

On Thursday 12 April 2007 12:12, Al Viro wrote: On Thu, Apr 12, 2007 at 02:08:10AM -0700, [EMAIL PROTECTED] wrote: This is needed for computing pathnames in the AppArmor LSM. Which is an argument against said LSM in current form. The fundamental model of AppArmor is to perform access checks

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

On Thursday 24 May 2007 03:28, James Morris wrote: On Wed, 23 May 2007, Andreas Gruenbacher wrote: This is backwards from what AppArmor does. The policy defines which paths may be accessed; all paths not explicitly listed are denied. If files are mounted at multiple locations

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

On Thursday 24 May 2007 15:19, James Morris wrote: On Thu, 24 May 2007, Andreas Gruenbacher wrote: Would you mind providing some concrete examples of how such a model would be useful? The model is explained, with examples, in the technical documentation at http://forgeftp.novell.com

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

On Thursday 24 May 2007 20:40, Al Viro wrote: On Thu, May 24, 2007 at 08:10:00PM +0200, Andreas Gruenbacher wrote: Read it like this: we don't have a good idea how to support multiple namespaces so far. Currently, we interpret all pathnames relative to the namespace a process

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

On Thursday 24 May 2007 20:58, Casey Schaufler wrote: On Fedora zcat, gzip and gunzip are all links to the same file. I can imagine (although it is a bit of a stretch) allowing a set of users access to gunzip but not gzip (or the other way around). There are probably more sophisticated

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

On Saturday 26 May 2007 07:20, Kyle Moffett wrote: On May 24, 2007, at 14:58:41, Casey Schaufler wrote: On Fedora zcat, gzip and gunzip are all links to the same file. I can imagine (although it is a bit of a stretch) allowing a set of users access to gunzip but not gzip (or the other

Re: Pass struct vfsmount to the inode_create LSM hook

On Saturday 26 May 2007 14:09, Tetsuo Handa wrote: Hello. Andreas Gruenbacher wrote: exec { /usr/bin/gunzip } gzip, -9, some/file/to.gz; The above Perl code executes /usr/bin/gunzip and sets argv[0] to gzip, so this confirms that the value of argv[0] is arbitrary. Well great, we

Re: Pass struct vfsmount to the inode_create LSM hook

On Saturday 26 May 2007 16:44, Tetsuo Handa wrote: Hello. Andreas Gruenbacher wrote: Therefore, TOMOYO Linux checks the combination of filename and argv[0] passed to execve(). So you are indeed trying to control the value of argv[0]? Well, good luck with that, but it's totally

Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSMhook

On Tuesday 29 May 2007 12:46, Tetsuo Handa wrote: But, from the pathname-based access control's point of view, bind mount interferes severely with pathname-based access control because it is impossible to determine which pathname was requested. Wrong. It is very well possible to determine the

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

On Wednesday 06 June 2007 15:26, Stephen Smalley wrote: On Mon, 2007-06-04 at 23:03 +0200, Andreas Gruenbacher wrote: [...] SELinux turns pathnames into labels when it initially labels all files (when a policy is rolled out), whereas AppArmor computes the label of each file when a file

Re: [AppArmor 38/45] AppArmor: Module and LSM hooks

On Saturday 09 June 2007 14:58, Pavel Machek wrote: How will kernel work with very long paths? I'd suspect some problems, if path is 1MB long and I attempt to print it in /proc somewhere. Pathnames are only used for informational purposes in the kernel, except in AppArmor of

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

On Saturday 09 June 2007 10:10, Sean wrote: Clinging to the current AA implementation instead of honestly considering reasonable alternatives does not inspire confidence or teamwork. What you imply is pretty insulting. I can assure you we looked into many possible implementation choices, and

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

On Saturday 16 June 2007 01:49, Greg KH wrote: But for those types of models that do not map well to internal kernel structures, perhaps they should be modeled on top of a security system that does handle the internal kernel representation of things in the way the kernel works. How exactly

Re: [PATCH try #2] security: Convert LSM into a static interface

On Monday 25 June 2007 06:33, James Morris wrote: Convert LSM into a static interface, as the ability to unload a security module is not required by in-tree users and potentially complicates the overall security architecture. It's useful for some LSMs to be modular, and LSMs which are y/n

Re: [AppArmor 00/44] AppArmor security module overview

On Wednesday 27 June 2007 12:58, Kyle Moffett wrote: I seem to recall you could actually end up racing and building a path to the file in those directories as a/d/0/3 or some other path at which it never even remotely existed. I'd love to be wrong, Cheer up, you recall wrong. but I can't

Re: [RFD 0/4] AppArmor - Don't pass NULL nameidata to vfs_create/lookup/permission IOPs

On Wednesday 27 June 2007 01:46, Trond Myklebust wrote: On Tue, 2007-06-26 at 16:15 -0700, [EMAIL PROTECTED] wrote: To remove conditionally passing of vfsmounts to the LSM, a nameidata struct can be instantiated in the nfsd and mqueue filesystems. This however results in useless

Re: [AppArmor 32/44] Enable LSM hooks to distinguish operations on file descriptors from operations on pathnames

On Tuesday 03 July 2007 15:49, Stephen Smalley wrote: So you don't actually need/use the struct file pointer; you just need a flag indicating whether or not access was by open file descriptor or by pathname? Yes, indeed. Given that struct iattr already defines ATTR_FILE and ia_file, I didn't

Re: [AppArmor 01/44] Pass struct vfsmount to the inode_create LSM hook

On Saturday 30 June 2007 11:29, Christoph Hellwig wrote: On Tue, Jun 26, 2007 at 04:07:57PM -0700, [EMAIL PROTECTED] wrote: This is needed for computing pathnames in the AppArmor LSM. Please see the various per-mountpoint r/o thread that NACKed all the vfsmount additions and have the

Re: Adding a security parameter to VFS functions

On Wednesday 15 August 2007 18:23, Casey Schaufler wrote: Hi Linus, Al, Would you object greatly to functions like vfs_mkdir() gaining a security parameter? Could you describe how this compares to the proposal that the AppArmor developers suggested recently? I expect that we can

Re: Adding a security parameter to VFS functions

On Wednesday 15 August 2007 13:40, David Howells wrote: Hi Linus, Al, Would you object greatly to functions like vfs_mkdir() gaining a security parameter? What I'm thinking of is this: int vfs_mkdir(struct inode *dir, struct dentry *dentry, int mode, struct

Re: Adding a security parameter to VFS functions

the fundamental model or the slow path / worst case. -- Andreas Gruenbacher [EMAIL PROTECTED] SUSE Labs, SUSE Linux Products GmbH - To unsubscribe from this list: send the line unsubscribe linux-security-module in the body of a message to [EMAIL PROTECTED] More majordomo info at http

Re: [AppArmor 32/45] Enable LSM hooks to distinguish operations on file descriptors from operations on pathnames

On Friday 26 October 2007 13:30, Miklos Szeredi wrote: There's a slight problem (other than HCH not liking it) with this approach of passing the open file in iattr: for special files, the struct file pointer makes no sense to the filesystem, since it is always opened by the generic functions.

Re: [AppArmor 00/45] AppArmor security module overview

On Friday 26 October 2007 16:37, Arjan van de Ven wrote: In addition, I'd like to ask you to put a file in Documentation/ somewhere that describes what AppArmor is intended security protection is (it's different from SELinux for sure for example); by having such a document for each LSM user,

Re: [AppArmor 32/45] Enable LSM hooks to distinguish operations on file descriptors from operations on pathnames

On Friday 26 October 2007 22:58:11 Miklos Szeredi wrote: For special files, f_op-fsetattr will be NULL, since init_special_inode() will set up i_fop that way. So the filesystem's fsetattr() will only be called for regular files and/or directories, depending on how it sets up i_fop. With the

Re: [AppArmor 00/45] AppArmor security module overview

On Saturday 27 October 2007 22:47, Christoph Hellwig wrote: On Fri, Oct 26, 2007 at 07:37:21AM -0700, Arjan van de Ven wrote: before going into the LSM / security side of things, I'd like to get the VFS guys to look at your VFS interaction code. It's been NACKed a few times, and just

[PATCH v3 2/7] selinux: Add accessor functions for inode->i_security

Add functions dentry_security and inode_security for accessing inode->i_security. These functions initially don't do much, but they will later be used to revalidate the security labels when necessary. Signed-off-by: Andreas Gruenbacher <agrue...@redhat.com> --- security/selinux/hook

[PATCH v3 1/7] selinux: Remove unused variable in selinux_inode_init_security

Signed-off-by: Andreas Gruenbacher <agrue...@redhat.com> --- security/selinux/hooks.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c index e4369d8..fc8f626 100644 --- a/security/selinux/hooks.c +++ b/security/selinux/hooks.c @@ -2

[PATCH v3 3/7] selinux: Get rid of file_path_has_perm

Use path_has_perm directly instead. Signed-off-by: Andreas Gruenbacher <agrue...@redhat.com> --- security/selinux/hooks.c | 18 +++--- 1 file changed, 3 insertions(+), 15 deletions(-) diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c index 65e8689..d6b4dc9

[PATCH v3 5/7] security: Add hook to invalidate inode security labels

. If an inode does not have any dentries attached, we cannot reload its security label because we cannot use the getxattr inode operation. In that case, continue using the old, invalid label until a dentry becomes available. Signed-off-by: Andreas Gruenbacher <agrue...@redhat.com> --- include

[PATCH v3 0/7] Inode security label invalidation

nel=144416710207686=2 The patches are looking good from my point of view; is there anything else that needs addressing? Does SELinux have test suites that these patches could be tested agains? Thanks, Andreas Andreas Gruenbacher (7): selinux: Remove unused variable in selinux_inode_init_security selinux:

[PATCH v3 4/7] selinux: Push dentry down from {dentry,path,file}_has_perm

In dentry_has_perm, path_has_perm, and file_has_perm, push the dentry down to before avc_has_perm so that dentry_security can be used instead of inode_security. Since inode_has_perm now takes a dentry, rename it to __dentry_has_perm. Signed-off-by: Andreas Gruenbacher <agrue...@redhat.

[PATCH v3 6/7] selinux: Revalidate invalid inode security labels

ter.) Signed-off-by: Andreas Gruenbacher <agrue...@redhat.com> --- security/selinux/hooks.c | 47 +++ 1 file changed, 39 insertions(+), 8 deletions(-) diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c index f93dafd..61aead9 100644 --- a

Re: [PATCH v3 2/7] selinux: Add accessor functions for inode->i_security

On Tue, Oct 27, 2015 at 6:20 PM, Stephen Smalley <s...@tycho.nsa.gov> wrote: > On 10/26/2015 05:15 PM, Andreas Gruenbacher wrote: >> @@ -2217,7 +2231,7 @@ static int selinux_bprm_set_creds(struct >> linux_binprm *bprm) >> >> old_tsec = current_security();

Re: [PATCH v4 6/7] selinux: Revalidate invalid inode security labels

On Thu, Oct 29, 2015 at 4:21 PM, Stephen Smalley <s...@tycho.nsa.gov> wrote: > On 10/28/2015 08:47 PM, Andreas Gruenbacher wrote: >> >> When fetching an inode's security label, check if it is still valid, and >> try reloading it if it is not. Reloading will fail when we

Re: [PATCH v3 0/7] Inode security label invalidation

On Wed, Oct 28, 2015 at 10:12 PM, Paul Moore <p...@paul-moore.com> wrote: > On Mon, Oct 26, 2015 at 5:15 PM, Andreas Gruenbacher > <agrue...@redhat.com> wrote: >> Here is another version of the patch queue to make gfs2 and similar file >> systems work with SELinux. A

[PATCH v4 1/7] selinux: Remove unused variable in selinux_inode_init_security

Signed-off-by: Andreas Gruenbacher <agrue...@redhat.com> Acked-by: Stephen Smalley <s...@tycho.nsa.gov> --- security/selinux/hooks.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c index e4369d8..fc8f626 100644 --- a/secu

[PATCH v4 6/7] selinux: Revalidate invalid inode security labels

ter.) When reloading fails, continue using the old, invalid label. Signed-off-by: Andreas Gruenbacher <agrue...@redhat.com> --- security/selinux/hooks.c | 70 1 file changed, 65 insertions(+), 5 deletions(-) diff --git a/security/selinux/

[PATCH v4 7/7] gfs2: Invalide security labels of inodes when they go invalid

reacquiring the glock. Signed-off-by: Andreas Gruenbacher <agrue...@redhat.com> Cc: Steven Whitehouse <swhit...@redhat.com> Cc: Bob Peterson <rpete...@redhat.com> Cc: cluster-de...@redhat.com --- fs/gfs2/glops.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/gfs2/glops.c b/fs/

[PATCH v5 2/7] security: Make inode argument of inode_getsecurity non-const

Make the inode argument of the inode_getsecurity hook non-const so that we can use it to revalidate invalid security labels. Signed-off-by: Andreas Gruenbacher <agrue...@redhat.com> Acked-by: Stephen Smalley <s...@tycho.nsa.gov> --- include/linux/lsm_hooks.h | 2 +- include/linu

[PATCH v5 5/7] security: Add hook to invalidate inode security labels

Add a hook to invalidate an inode's security label when the cached information becomes invalid. Add the new hook in selinux: set a flag when a security label becomes invalid. Signed-off-by: Andreas Gruenbacher <agrue...@redhat.com> Reviewed-by: James Morris <james.l.mor...@oracle.c

Re: [PATCH v4 6/7] selinux: Revalidate invalid inode security labels

Paul, On Sun, Nov 1, 2015 at 1:52 PM, Paul Moore wrote: > If you want, you can just post a > "8/7" patch with the extra calls added and I'll apply that on top of > the v4 patchset. I've also added the additional Acked-by headers, it's easiest to just repost (I just did).

[PATCH v5 3/7] security: Make inode argument of inode_getsecid non-const

Make the inode argument of the inode_getsecid hook non-const so that we can use it to revalidate invalid security labels. Signed-off-by: Andreas Gruenbacher <agrue...@redhat.com> Acked-by: Stephen Smalley <s...@tycho.nsa.gov> --- include/linux/audit.h | 8 i

[PATCH v5 4/7] selinux: Add accessor functions for inode->i_security

Add functions dentry_security and inode_security for accessing inode->i_security. These functions initially don't do much, but they will later be used to revalidate the security labels when necessary. Signed-off-by: Andreas Gruenbacher <agrue...@redhat.com> Acked-by: Stephen S

[PATCH v5 0/7] Inode security label invalidation

(sock) inodes. This patch queue is also available here: git://git.kernel.org/pub/scm/linux/kernel/git/agruen/linux.git selinux-wip Thanks, Andreas Andreas Gruenbacher (7): selinux: Remove unused variable in selinux_inode_init_security security: Make inode argument of inode_getsecurity non

[PATCH v5 6/7] selinux: Revalidate invalid inode security labels

ter.) When reloading fails, continue using the old, invalid label. Signed-off-by: Andreas Gruenbacher <agrue...@redhat.com> Acked-by: Stephen Smalley <s...@tycho.nsa.gov> --- security/selinux/hooks.c | 76 +++- 1 file changed, 68 insertions(

[PATCH v5 1/7] selinux: Remove unused variable in selinux_inode_init_security

Signed-off-by: Andreas Gruenbacher <agrue...@redhat.com> Acked-by: Stephen Smalley <s...@tycho.nsa.gov> --- security/selinux/hooks.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c index e4369d8..fc8f626 100644 --- a/secu

[PATCH] selinux: Inode label revalidation performance fix

to roughly the original performance. Signed-off-by: Andreas Gruenbacher <agrue...@redhat.com> --- security/selinux/hooks.c | 10 ++ 1 file changed, 2 insertions(+), 8 deletions(-) diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c index 40e071a..f8110cf 100644 --- a/se