Re: [RFC] The reflink(2) system call v4.

[Stephen Smalley <sds@tycho.nsa.gov>]

On Thu, 2009-05-14 at 15:00 -0700, Joel Becker wrote:
> On Thu, May 14, 2009 at 02:12:45PM -0400, Stephen Smalley wrote:
> > On Wed, 2009-05-13 at 23:57 -0400, Andy Lutomirski wrote:
> > > 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
> > 
> > Yes, I agree - the selection of whether or not to preserve the security
> > attributes should be an explicit part of the kernel interface.  Then the
> > application still has the freedom to fall back on the non-preserving
> > form of the call if that is truly what it wants.
> 
> 	Here's my problem.  Every single shell script now has to do:
> 
>     ln -r source target
>     [ $? != 0 ] && ln -r --no-perms source target
> 
> Every single program now has to do:
> 
>     if (reflink(source, target) && errno == EPERM)
>         reflinkat(AT_FDCWD, source, AT_FDCWD, target, 0, REFLINK_NOPERMS);
> 
> Because the 99% user wants a real snapshot, and doesn't want to have to
> think about it.  The could, of course, code up their own permission
> checks to see which variant of reflink to call, but it's still useless
> (to them) boilerplate.
> 	Also, if the 'common' user has to use the reflinkat() call?
> We've lost.

I think Jamie covered the fact that you can provide a user interface and
library functions that provide the "simpler" interface on top of this
interface, but not vice versa.

> 	Finally, how is this safer?  Don't get me wrong, I do respect
> the concern - that's why I originally went with your proposal of
> is_owner_or_cap().  But the fact is that if you've hijacked a process
> with enough privileges, you *can* make the full reflink, and if your
> hijacked process doesn't but does have read access, you *can* make the
> NOPERMS reflink.  So doing it with the userspace code above is identical
> to the kernel code, except that every userspace program has to handle it
> themselves.

As Jamie said, we aren't talking about injecting arbitrary code into the
process.  The failure scenario is quite similar to the setuid() one:
arrange conditions such that the process lacks sufficient privileges to
preserve attributes, and when it calls reflink(2) expecting to preserve
the attributes, it will get no indication that they weren't preserved.
At which point the data may be unwittingly exposed beyond its original
constraints.

-- 
Stephen Smalley
National Security Agency