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: <20080602123244.GC8562@parisc-linux.org>
Date:	Mon, 2 Jun 2008 06:32:46 -0600
From:	Matthew Wilcox <matthew@....cx>
To:	Miklos Szeredi <miklos@...redi.hu>
Cc:	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,
	agruen@...e.de, 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 Mon, Jun 02, 2008 at 01:52:21PM +0200, Miklos Szeredi wrote:
> Found it:
> 
>    http://lkml.org/lkml/2008/4/9/98
> 
> I did not take part in that discussion and could not have been able to
> contribute anyway.  From a cursory read of the thread, the idea was
> good, but not entirely applicable to apparmor.  Or did I miss
> something?

Sorry, I thought you were on the CC for that.

The conversation was somewhat unclear, at least in part because I'd
misunderstood the apparmour deny vs allow logic.  It was also extremely
unhelpful when certain people decided to have a debate about path-name
based security.  So let me try again.

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.

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*).

-- 
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."
--
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/