linux-kernel - Re: [patch 01/15] security: pass path to inode

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200806021445.13831.agruen@suse.de>
Date:	Mon, 2 Jun 2008 14:45:10 +0200
From:	Andreas Gruenbacher <agruen@...e.de>
To:	Matthew Wilcox <matthew@....cx>
Cc:	Miklos Szeredi <miklos@...redi.hu>, hch@...radead.org,
	linux-security-module@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, jmorris@...ei.org,
	sds@...ho.nsa.gov, eparis@...hat.com, casey@...aufler-ca.com,
	jjohansen@...e.de, penguin-kernel@...ove.sakura.ne.jp,
	viro@...iv.linux.org.uk, linux-kernel@...r.kernel.org
Subject: Re: [patch 01/15] security: pass path to inode_create

On Monday 02 June 2008 14:32:46 Matthew Wilcox wrote:
> The point is to resolve pathnames into dev_t + inode in the
> context where the rule is set up.  Then you can implement (say)
> security_inode_permission() without needing to pass in a vfsmount -- all
> you need are the inode->i_ino and inode->i_sb->s_dev to do a comparison.

Without the vfsmount, when something is mounted in more than once place, you 
cannot report which of the name aliases a process is accessing. This is 
unacceptable; the logs would become unusable. With pathname-based, the 
AppArmor and TOMOYO folks really mean pathname-based, not a hybrid pathname / 
mount point model.

> Yes, if someone mounts /etc onto /etc2/ and has a rule to allow them to
> access /etc/shadow, they will then be able to access /etc2/shadow as
> well (which they weren't able to under previous apparmour).  But I can't
> think of a way that permits Something Bad to happen (since the contents
> of the file could have been accessed through /etc/shadow *anyway*).

Yes, when a security policy specifies different permissions for the same 
object on different paths, processes are of course limited to the least 
restrictive of those paths.

One consequence of this is that pathname-based models must control who is 
allowed to create aliases where, of course.

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