linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Toshiharu Harada" <haradats@gmail.com>
To: "Evgeniy Polyakov" <johnpol@2ka.mipt.ru>
Cc: "Miklos Szeredi" <miklos@szeredi.hu>,
	hch@infradead.org, linux-security-module@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, jmorris@namei.org,
	sds@tycho.nsa.gov, eparis@redhat.com, casey@schaufler-ca.com,
	agruen@suse.de, jjohansen@suse.de,
	penguin-kernel@i-love.sakura.ne.jp, viro@zeniv.linux.org.uk,
	linux-kernel@vger.kernel.org
Subject: Re: [patch 01/15] security: pass path to inode_create
Date: Tue, 3 Jun 2008 08:37:52 +0900	[thread overview]
Message-ID: <9d732d950806021637q5527398boad7cb54ae5f26662@mail.gmail.com> (raw)
In-Reply-To: <20080602165223.GA9121@2ka.mipt.ru>

2008/6/3 Evgeniy Polyakov <johnpol@2ka.mipt.ru>:
> On Tue, Jun 03, 2008 at 01:29:33AM +0900, Toshiharu Harada (haradats@gmail.com) wrote:
>> > 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 :)
>>
>> This is a very important point.
>>
>> The world of Linux consists of the two pieces, userland and kernel.
>> Objects have names and inodes. Information flow control need to be
>> handled using inodes (labels), but pathnames need to be
>> controlled because objects are represented by names in userland.
>> Both pieces work together. Vfsmount is a missing piece.
>>
>> AppArmor and TOMOYO Linux are not claiming they are better MAC for Linux.
>> (that's how I understood Stephen's words. I am agreed)
>> So people don't have to eliminate pathname-based MACs.
>
> They can, if really want, to get vfsmount.
>
> A hint: there is security_sb_check_sb() and security_sb_post_addmount().
> Store that vsmount in private cache, search the very root dentry for any inode
> inside that cache of vfsmounts and get a pointer. Looks a bit ugly
> though, and slower (really a bit), but it can solve a problem.
> It is also possible to implement own path cache isntead of using dentry
> cache, since apparently dentry is not needed neither to apparmor nor to
> tomoyo, but path info (in own format). And that will be even better
> solution, since it will be exactly what selinux does with its data.
> Only to different objects. This will complicate move/rename and other
> pathname manipulation. There are of course underwater rocks, but they
> can be worked out with existing inode-biased approach.
>
> --
>        Evgeniy Polyakov

Actually, another option has been suggested last month.
http://lkml.org/lkml/2008/4/9/93

Miklos' patches seem to me well suited after vfs cleanup jobs, but...

-- 
Toshiharu Harada
haradats@gmail.com

  reply	other threads:[~2008-06-02 23:37 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-29 13:49 [patch 00/15] security: pass path instead of inode to security ops Miklos Szeredi
2008-05-29 13:49 ` [patch 01/15] security: pass path to inode_create Miklos Szeredi
2008-05-31  8:30   ` Christoph Hellwig
2008-05-31 10:48     ` Tetsuo Handa
2008-06-01 20:52     ` Miklos Szeredi
2008-06-02  6:01       ` Christoph Hellwig
2008-06-02  7:02         ` Miklos Szeredi
2008-06-02  9:13           ` Christoph Hellwig
2008-06-02  9:32             ` Miklos Szeredi
2008-06-02  9:36               ` Christoph Hellwig
2008-06-02  9:52                 ` Miklos Szeredi
2008-06-02 10:42                   ` Christoph Hellwig
2008-06-02 10:55                     ` Miklos Szeredi
2008-06-02 11:04                       ` Pekka Enberg
2008-06-02 11:13                         ` Miklos Szeredi
2008-06-02 15:05                       ` Evgeniy Polyakov
2008-06-02 15:31                         ` Toshiharu Harada
2008-06-02 15:51                           ` Evgeniy Polyakov
2008-06-02 16:29                             ` Toshiharu Harada
2008-06-02 16:52                               ` Evgeniy Polyakov
2008-06-02 23:37                                 ` Toshiharu Harada [this message]
2008-06-03  6:08                                   ` Miklos Szeredi
2008-06-02 18:59                     ` Serge E. Hallyn
2008-06-02 10:04             ` Andreas Gruenbacher
2008-06-02 11:23           ` Matthew Wilcox
2008-06-02 11:34             ` Miklos Szeredi
2008-06-02 11:52               ` Miklos Szeredi
2008-06-02 12:32                 ` Matthew Wilcox
2008-06-02 12:45                   ` Andreas Gruenbacher
2008-06-02 12:49                     ` Matthew Wilcox
2008-06-02 13:24                       ` Andreas Gruenbacher
2008-06-14  8:27                     ` Tetsuo Handa
2008-06-03 13:43   ` Stephen Smalley
2008-06-04  5:09     ` Tetsuo Handa
2008-05-29 13:49 ` [patch 02/15] security: pass path to inode_mknod Miklos Szeredi
2008-05-29 13:49 ` [patch 03/15] security: pass path to inode_mkdir Miklos Szeredi
2008-05-29 13:49 ` [patch 04/15] security: pass path to inode_rmdir Miklos Szeredi
2008-05-29 13:49 ` [patch 05/15] security: pass path to inode_unlink Miklos Szeredi
2008-05-29 13:49 ` [patch 06/15] security: pass path to inode_symlink Miklos Szeredi
2008-05-29 13:49 ` [patch 07/15] security: pass path to inode_link Miklos Szeredi
2008-05-29 13:49 ` [patch 08/15] security: pass path to inode_rename Miklos Szeredi
2008-05-29 13:49 ` [patch 09/15] security: pass path to inode_setattr Miklos Szeredi
2008-05-29 13:49 ` [patch 10/15] security: pass path to inode_getxattr Miklos Szeredi
2008-05-29 13:49 ` [patch 11/15] security: pass path to inode_listxattr Miklos Szeredi
2008-05-29 13:49 ` [patch 12/15] security: pass path to inode_setxattr Miklos Szeredi
2008-05-29 13:49 ` [patch 13/15] security: pass path to inode_removexattr Miklos Szeredi
2008-05-29 13:49 ` [patch 14/15] vfs: more path_permission() conversions Miklos Szeredi
2008-05-29 13:49 ` [patch 15/15] security: pass path to inode_permission Miklos Szeredi
2008-05-30 13:37 ` [patch 00/15] security: pass path instead of inode to security ops Tetsuo Handa
2008-05-30 17:17   ` Miklos Szeredi
2008-05-31  0:33     ` Tetsuo Handa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9d732d950806021637q5527398boad7cb54ae5f26662@mail.gmail.com \
    --to=haradats@gmail.com \
    --cc=agruen@suse.de \
    --cc=casey@schaufler-ca.com \
    --cc=eparis@redhat.com \
    --cc=hch@infradead.org \
    --cc=jjohansen@suse.de \
    --cc=jmorris@namei.org \
    --cc=johnpol@2ka.mipt.ru \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=penguin-kernel@i-love.sakura.ne.jp \
    --cc=sds@tycho.nsa.gov \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).