|From:||Andy Lutomirski <luto-AT-mit.edu>|
|To:||jim owens <jowens-AT-hp.com>, jmorris-AT-namei.org, ocfs2-devel-AT-oss.oracle.com, viro-AT-zeniv.linux.org.uk, mtk.manpages-AT-gmail.com, linux-security-module-AT-vger.kernel.org, linux-fsdevel-AT-vger.kernel.org|
|Subject:||Re: [RFC] The reflink(2) system call v4.|
|Date:||Wed, 13 May 2009 23:57:58 -0400|
Joel Becker wrote: > + > +Preserving the security context of the source file obviously requires > +the privilege to do so. Callers that do not own the source file and do > +not have CAP_CHOWN will get a new reflink with all non-security > +attributes preserved; the security context of the new reflink will be > +as a newly created file by that user. > + There are plenty of syscalls that require some privilege and fail if the caller doesn't have it. But I can think of only one syscall that does *something different* depending on who called it: setuid. Please search the web and marvel at the disasters caused by setuid's magical caller-dependent behavior (the sendmail bug is probably the most famous ). This proposal for reflink is just asking for bugs where an attacker gets some otherwise privileged program to call reflink but to somehow lack the privileges (CAP_CHOWN, selinux rights, or whatever) to copy security attributes, thus exposing a link with the wrong permissions. Would it really be that hard to have two syscalls, or a flag, or whatever, where one of them preserves all security attributes and *fails* if the caller isn't allowed to do that and the other one makes the caller own the new link?  http://www.cs.berkeley.edu/~daw/papers/setuid-usenix02.pdf --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to email@example.com More majordomo info at http://vger.kernel.org/majordomo-info.html
Copyright © 2009, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds