From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Lutomirski Subject: Re: [RFC] The reflink(2) system call v4. Date: Wed, 13 May 2009 23:57:58 -0400 Message-ID: <4A0B96C6.40702@mit.edu> References: <1241331303-23753-1-git-send-email-joel.becker@oracle.com> <20090507221535.GA31624@mail.oracle.com> <4A039FF8.7090807@hp.com> <20090508031018.GB8611@mail.oracle.com> <20090511204011.GB30293@mail.oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit To: jim owens , jmorris@namei.org, ocfs2-devel@oss.oracle.com, viro@zeniv.linux.org.uk, mtk.manpages@gmail.com, linux-security-module@vger.kernel.org, linux-fsdevel@vger.kernel.org Return-path: Received: from 207-172-69-77.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com ([207.172.69.77]:48978 "EHLO thaum.luto.us" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750831AbZENEJD (ORCPT ); Thu, 14 May 2009 00:09:03 -0400 In-Reply-To: <20090511204011.GB30293@mail.oracle.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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 [1]). 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? [1] http://www.cs.berkeley.edu/~daw/papers/setuid-usenix02.pdf --Andy From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Lutomirski Date: Wed, 13 May 2009 23:57:58 -0400 Subject: [Ocfs2-devel] [RFC] The reflink(2) system call v4. In-Reply-To: <20090511204011.GB30293@mail.oracle.com> References: <1241331303-23753-1-git-send-email-joel.becker@oracle.com> <20090507221535.GA31624@mail.oracle.com> <4A039FF8.7090807@hp.com> <20090508031018.GB8611@mail.oracle.com> <20090511204011.GB30293@mail.oracle.com> Message-ID: <4A0B96C6.40702@mit.edu> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: jim owens , jmorris@namei.org, ocfs2-devel@oss.oracle.com, viro@zeniv.linux.org.uk, mtk.manpages@gmail.com, linux-security-module@vger.kernel.org, linux-fsdevel@vger.kernel.org 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 [1]). 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? [1] http://www.cs.berkeley.edu/~daw/papers/setuid-usenix02.pdf --Andy