Quoting Eric W. Biederman (ebiederm@xxxxxxxxxxxx): > "Serge E. Hallyn" <serue@xxxxxxxxxx> writes: > > > > Ok, but this is all done as root. Kind of a silly thing for root to > > do :) > > There are less silly examples like setting up a chroot type > environment contained in a mount namespace and having a kernel oops > and then not being able to delete all of your files. I wasn't saying that I believe I can win an argument by knocking down one example :) In fact I'm not trying to win an argument. Because I'm quite sure you and Miklos are right, and I just need to figure out what I'm missing. > > So in order for me as an unprivileged user to pin a dentry by mounting > > over it, I have to have write permission to the dentry to begin with > > as well as the dentry being under a user=hallyn mount. > > That second condition is interesting requiring write permission of the > dentry. I thought we had obviated the need for that when we added > ownership to the mounts themselves. In this case at least it shouldn't > it be write permission on the directory containing the dentry. Oh no, it seems I'm wrong, that's not a condition. Just tested it. > >> Now you can't create /etc/passwd.new and rename it to /etc/passwd. > >> Stopping adduser from working. > >> > >> As Miklos said this can apply to any file or any directory, so it can > >> be a DOS against any other user on the system. > > > > Except I need to own the mount as well as the dentry. So after > > root does > > > > mmount --bind -o user=hallyn /home/hallyn /home/hallyn > > mmount --bind -o user=hallyn /home/serge /home/serge > > > > if user serge (uid 501) tries to > > > > mmount --bind /etc /home/hallyn/etc > > mmount --bind /etc /home/serge/etc > > > > permission for the first will be denied because serge does not > > have write perms to /home/hallyn/etc, and permission for the second > > will be denied because only hallyn may mount under /home/serge. > > > > If root properly did > > > > mmount --bind -o user=hallyn /home/hallyn /home/hallyn > > mmount --bind -o user=serge /home/serge /home/serge > > > > and then hallyn does > > > > mmount --bind /etc /home/hallyn/etc > > > > and serge does > > > > mmount --bind /home/hallyn/etc /home/serge/etc > > > > then hallyn can still ummount /home/hallyn/etc. > > > > And we've decided that users cannot (for now) do shared mounts. > > So I'm still not sure where there is the potential for danger? > > Ok. Let's pick on something a little more interesting. > > root does: > mmount --bind -o user=hallyn /home/hallyn /home/hallyn > hallyn does: > mount --bind /tmp /home/hallyn/tmp > touch dummy > mount --bind dummy /home/hallyn/tmp/some_shared_file_I_have_write_access_to. > > Which allows me to transform write permissions into the ability to > deny someone else the ability to delete a file. Yup, that's an interesting example. Still an admin *can* work around that, if he can sufficiently parse /proc/self/mountinfo to know to umount /home/hallyn/tmp/some_shared_file_I_have_write_access_to. Is that sufficient? Probably not? > This seems to mess up things like revoke. Hey, do we have revoke now? :) > At a practical level it is a real annoyance, regardless of the security > implications. > > As a point of comparison plan9 does not have that restriction. Why doesn't it have that restriction? Does it always allow you to rm a mounted-over file? -serge -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
