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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Mon, 2 Jun 2008 19:51:52 +0400
From:	Evgeniy Polyakov <johnpol@....mipt.ru>
To:	Toshiharu Harada <haradats@...il.com>
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,
	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 Tue, Jun 03, 2008 at 12:31:14AM +0900, Toshiharu Harada (haradats@...il.com) wrote:
> > This is a really interesting flame, can you proceed,
> > we will run for cola and peanuts :)
> 
> Let me quote a message by Chris Wright from LSM ml:
> "You cannot discover the path used to access an inode without knowing
> both the dentry and the vfsmount objects. "

Depending on what path you really want. If you want it related to bind
mount, you can (trivially). And even full path with vfsmount with
additional work.

Without any single additional patch on top of security system.

It maybe a bit slower, more complex, duplicate, whatever...
Active security was never a fast solution and was never a compromiss
between those who like it and who do not.

Technically you can be inside created limits and formally do not change
security model, but in practice implement you lovely path based security
checks.

> Another one by Stephen Smalley:
> "Pathname-based security considered harmful.  You want to control access
> to an object, not a name, and the name-to-object mapping is neither
> one-to-one nor immutable."

For those who care exactly about path, they do not want to have security
checks for object, which was there. As addition, selinux
maintainer/architector opinion is a bit biassed :)

> Can you guess when they were posted?
> The answer is December 2003. :)
> Do we need more time? I don't think so.

Apparently we do :)

> I'm viewing Miklos' patches as *enhancements* not only for AppArmor (and
> other pathname-based LSM modules). Everyone can make use of
> information and lose nothing.  Am I too simple minded?

What I wanted to say, is that people who do want to implement theirs
idea, will find a way to do it without breaking other approach.
With additional changes, with more complex approach, more code and
possibly some duplication/optimization/whatever.

So, if people continue to kick theirs head to the wall, they want
exactly that flame, that void talks and so on :)

-- 
	Evgeniy Polyakov
--
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/