[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <200806141727.ADG13075.FOVHFSFQtOJLOM@I-love.SAKURA.ne.jp>
Date: Sat, 14 Jun 2008 17:27:41 +0900
From: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To: hch@...radead.org
Cc: linux-security-module@...r.kernel.org,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [patch 01/15] security: pass path to inode_create
Quoting Christoph wrote:
> Well, pathname based access control is a dumb idea, and we've been
> through this N times.
I have a question for you.
Matthew Wilcox wrote:
> 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*).
No. Something Bad happens even if you use object based access controls.
Andreas Gruenbacher wrote:
> One consequence of this is that pathname-based models must control who is
> allowed to create aliases where, of course.
The object based access controls *also* have to care about pathnames,
or Something Bad happens.
Have you ever thought that the pathname plays some part of security?
Please read part 3 and part 4 of http://lkml.org/lkml/2008/4/12/63 if
you have never thought that.
"Applications depend on pathnames, not on inode's number or labels.
Thinking little of pathnames leads to serious result."
Why do you think it is a bad thing to implement an access control that
restricts pathnames?
--
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/
Powered by blists - more mailing lists