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.
next parent 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox