All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bodo Eggert <7eggert@gmx.de>
To: Al Viro <viro@ftp.linux.org.uk>,
	John Johansen <jjohansen@suse.de>,
	akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
	linux-security-module@vger.kernel.org, Tony Jones <tonyj@suse.de>,
	Andreas Gruenbacher <agruen@suse.de>
Subject: Re: [AppArmor 19/45] Add struct vfsmount parameters to vfs_rename()
Date: Fri, 02 Nov 2007 11:14:14 +0100	[thread overview]
Message-ID: <E1IntXa-0001JL-Qw@be1.7eggert.dyndns.org> (raw)
In-Reply-To: 9iE8n-3zk-1@gated-at.bofh.it

Al Viro <viro@ftp.linux.org.uk> wrote:
> On Fri, Oct 26, 2007 at 11:23:53AM -0700, John Johansen wrote:

>> In the current code, both vfsmounts are always identical, and so one of
>> the two should go, agreed.
>> 
>> The thought behind passing both vfsmounts was that they could differ but
>> point to the same super_block, in which case renames would still be
>> possible at least from a filesystem point of view. The essential
>> restriction here is that both files must be on the same device; the vfs
>> restriction of not allowing cross-mount renames is arbitrary.
> 
> It's called "access control".  Pathname-based one, BTW.  And yes, it's
> 100% deliberate.

I doubt anybody uses bind mounts & co instead of symlinks in order to
prevent rename() while still allowing to move files by either copying
or by using the source file in the bound directory. At least I expected
bind mounted directories to behave like symlinked ones, minus the problems
of symlinks. 

Since this feature only protects you from rename(src/foo,dst/foo) if
1) There is no way to access src and dst in the same mount space
2) src and dst are writebale by the attacker
3) Unlinking src/foo is OK
4) Renaming src/foo is OK as long as it's within the same mount as foo
5) Symlinking src/foo to dst/foo is OK
6) Creating dst/foo having a different owner is OK
7) Having dst/foo with the original content and owner from src/foo is _not_ OK
8) Moon crashes on earth
, I'd rather like to have a fast mv.

>> Cross-mount renames are not allowed currently, and granted, they may not
>> be very useful, either.
> 
> <raised brows>
> Excuse me, but IIRC LSM was supposed to _add_ restrictions, not to remove
> existing security checks.

Security checks as in "we built a steel door into that Chinese paper wall"?

As far as I understand, the restriction would not be removed by the LSM
explicitely allowing it, but by the fixed vfs then being able to handle
cross-mountpoint-renames. Maybe yo'll want to keep the ability for the users
who use bind mounts in order to not allow rename() ... both of them.-)

/me prepares for the impact of a large round object on earth.


       reply	other threads:[~2007-11-02 10:50 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <9irkY-83N-5@gated-at.bofh.it>
     [not found] ` <9iruz-7b-23@gated-at.bofh.it>
     [not found]   ` <9irXD-Jf-25@gated-at.bofh.it>
     [not found]     ` <9iC6y-nT-1@gated-at.bofh.it>
     [not found]       ` <9iE8n-3zk-1@gated-at.bofh.it>
2007-11-02 10:14         ` Bodo Eggert [this message]
2007-11-02 12:28           ` [AppArmor 19/45] Add struct vfsmount parameters to vfs_rename() Peter Zijlstra
2007-10-26  6:40 [AppArmor 00/45] AppArmor security module overview jjohansen
2007-10-26  6:40 ` [AppArmor 19/45] Add struct vfsmount parameters to vfs_rename() jjohansen
2007-10-26  7:37   ` Al Viro
2007-10-26 18:23     ` John Johansen
2007-10-26 20:33       ` Al Viro
  -- strict thread matches above, loose matches on Subject: below --
2007-05-14 11:06 [AppArmor 00/45] AppArmor security module overview jjohansen
2007-05-14 11:06 ` [AppArmor 19/45] Add struct vfsmount parameters to vfs_rename() jjohansen

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=E1IntXa-0001JL-Qw@be1.7eggert.dyndns.org \
    --to=7eggert@gmx.de \
    --cc=agruen@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=jjohansen@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=tonyj@suse.de \
    --cc=viro@ftp.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.