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

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:	Wed, 07 Feb 2007 11:25:48 -0500
From:	Jeff Mahoney <jeffm@...e.de>
To:	Chris Wright <chrisw@...s-sol.org>
Cc:	Andreas Gruenbacher <agruen@...e.de>,
	Stephen Smalley <sds@...ho.nsa.gov>,
	Christoph Hellwig <hch@...radead.org>,
	Tony Jones <tonyj@...e.de>, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org,
	linux-security-module@...r.kernel.org, viro@...iv.linux.org.uk
Subject: Re: [RFC 0/28] Patches to pass vfsmount to LSM inode security hooks

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chris Wright wrote:
> * Andreas Gruenbacher (agruen@...e.de) wrote:
>> Reiserfs currently only marks the ".reiserfs_priv" directory as private, but 
>> not the files below it -- how about the attached patch to fix that?
> 
> I don't think that's right.  Look at ->create or ->lookup.  Both of those
> properly set the private flag.  This patch looks like a step backwards,
> sprinkling the init in so many places.

Yeah, this is exactly what happens. The flag is purposely only set once,
and then is inherited up the tree. I'm fine removing the helper
function, but the inheritance should be working fine. Have you seen
behavior that is contrary?

- -Jeff

>> Fix reiserfs xattrs for selinux
>>
>> Mark all inodes used for reiserfs xattrs as private so that selinux
>> (or any other LSM) will not try to mediate access to the files and
>> directories used as the xattr backing store. The xattr operations
>> are already protected through the xattr LSM hooks.
>>
>> There is no real reason for having reiserfs_mark_inode_private --
>> remove it and directly mark the inodes as private.
>>
>> Signed-off-by: Andreas Gruenbacher <agruen@...e.de>
>> Cc: Jeff Mahoney <jeffm@...e.de>
>>
>> Index: b/fs/reiserfs/xattr.c
>> ===================================================================
>> --- a/fs/reiserfs/xattr.c
>> +++ b/fs/reiserfs/xattr.c
>> @@ -79,6 +79,7 @@ static struct dentry *create_xa_root(str
>>  			dput(privroot);
>>  			return ERR_PTR(err);
>>  		}
>> +		xaroot->d_inode->i_flags |= S_PRIVATE;
> 
> Already handled in the above ->mkdir
> 
>>  		REISERFS_SB(sb)->xattr_root = dget(xaroot);
>>  	}
>>  
>> @@ -108,6 +109,7 @@ static struct dentry *__get_xa_root(stru
>>  		goto out;
>>  	}
>>  
>> +	xaroot->d_inode->i_flags |= S_PRIVATE;
> 
> Already handled during xa_root creation
> 
>>  	REISERFS_SB(s)->xattr_root = dget(xaroot);
>>  
>>        out:
>> @@ -183,6 +185,7 @@ static struct dentry *open_xa_dir(const 
>>  			return ERR_PTR(-ENODATA);
>>  		}
>>  	}
>> +	xadir->d_inode->i_flags |= S_PRIVATE;
> 
> Already handled in lookup or mkdir
> 
>>  	dput(xaroot);
>>  	return xadir;
>> @@ -235,6 +238,8 @@ static struct dentry *get_xa_file_dentry
>>  	dput(xadir);
>>  	if (err)
>>  		xafile = ERR_PTR(err);
>> +	else
>> +		xafile->d_inode->i_flags |= S_PRIVATE;
> 
> Already handled in lookup or create
> 
>>  	return xafile;
>>  }
>>  
>> @@ -715,6 +720,7 @@ __reiserfs_xattr_del(struct dentry *xadi
>>  		err = -ENODATA;
>>  		goto out_file;
>>  	}
> Already handled in lookup
> 
> etc...


- --
Jeff Mahoney
SUSE Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFFyf2MLPWxlyuTD7IRAnjYAJ40js54LOzv+xMqgSnbfeq6DIvJEACeIWhu
9QuXzrKspwXbh8qSx0o/tK8=
=rvqJ
-----END PGP SIGNATURE-----
-
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/