[RFC] Privilege escalation in filesystems

[RFC] Privilege escalation in filesystems

[Josef Sipek]

While going though the Unionfs code, Chris Wedgwood commented that it might
make sense to ask the list about temporary privilege escalation in file
systems.

Much like NFS, at times Unionfs has to perform operations as another user.
(See below for details as to when and why this has to happen.)

I'd like to know what the preferred way of doing that is. I noticed that NFS
does a simple assignment:

(fs/nfs/nfs4recover.c:nfs4_save_user)
current->fsuid = 0;
current->fsgid = 0;

Should the capabilities be set/dropped as well? Would it be worth it to
provide some kind of generic way of accomplishing this having file system
messing with current directly?


Unionfs specific details:
-------------------------

Namespace unification requires that there is a way to mark a directory
"opaque" - meaning that lookup/readdir should not merge the objects of this
directory with those of a directory of a lower priority. When one creates a
new, empty directory using mkdir(2), the new directory should be empty
according to POSIX/UNIX. To prevent contents of directories on lower
priority branches from appearing in this newly created directory, the
directory is made opaque.

Suppose we have a union of /mnt/a and /mnt/b that are initially empty. Then
we perform the following steps:

$ cd /union
$ mkdir foo
$ find /union
/union/
/union/foo/
$ find /mnt/
/mnt/
/mnt/a/
/mnt/a/foo/
/mnt/a/foo/.wh.__dir_opaque
/mnt/b/

The .wh.__dir_opaque informs our implementation of Unionfs that the
directory is opaque.

The privilege problem appears when we try to remove the directory foo. If
we have write permission to /union, we should be able to remove any file or
(empty) directory. In the above example, /union/foo is empty.
If the foo is owned by someone else and we don't have write permission to
it, we'll fail to remove the opaque whiteout from foo (.wh.__dir_opaque),
which would in turn prevent us from removing foo itself. If we become a
superuser temporarily, we can remove the whiteout as well as the directory,
and all is well.

Josef "Jeff" Sipek.

-- 
UNIX is user-friendly ... it's just selective about who it's friends are

Re: [RFC] Privilege escalation in filesystems

[Trond Myklebust]

On Wed, 2006-08-09 at 17:52 -0400, Josef Sipek wrote:
> While going though the Unionfs code, Chris Wedgwood commented that it might
> make sense to ask the list about temporary privilege escalation in file
> systems.
> 
> Much like NFS, at times Unionfs has to perform operations as another user.
> (See below for details as to when and why this has to happen.)
> 
> I'd like to know what the preferred way of doing that is. I noticed that NFS
> does a simple assignment:
> 
> (fs/nfs/nfs4recover.c:nfs4_save_user)
> current->fsuid = 0;
> current->fsgid = 0;

This sort of thing can be defeated by selinux. The right way to perform
privileged operations is normally to give the task to a kernel thread
that has the required privileges (for instance a work_queue like
keventd).

> Should the capabilities be set/dropped as well? Would it be worth it to
> provide some kind of generic way of accomplishing this having file system
> messing with current directly?
> 
> 
> Unionfs specific details:
> -------------------------
> 
> Namespace unification requires that there is a way to mark a directory
> "opaque" - meaning that lookup/readdir should not merge the objects of this
> directory with those of a directory of a lower priority. When one creates a
> new, empty directory using mkdir(2), the new directory should be empty
> according to POSIX/UNIX. To prevent contents of directories on lower
> priority branches from appearing in this newly created directory, the
> directory is made opaque.
> 
> Suppose we have a union of /mnt/a and /mnt/b that are initially empty. Then
> we perform the following steps:
> 
> $ cd /union
> $ mkdir foo
> $ find /union
> /union/
> /union/foo/
> $ find /mnt/
> /mnt/
> /mnt/a/
> /mnt/a/foo/
> /mnt/a/foo/.wh.__dir_opaque
> /mnt/b/
> 
> The .wh.__dir_opaque informs our implementation of Unionfs that the
> directory is opaque.
> 
> The privilege problem appears when we try to remove the directory foo. If
> we have write permission to /union, we should be able to remove any file or
> (empty) directory. In the above example, /union/foo is empty.
> If the foo is owned by someone else and we don't have write permission to
> it, we'll fail to remove the opaque whiteout from foo (.wh.__dir_opaque),
> which would in turn prevent us from removing foo itself. If we become a
> superuser temporarily, we can remove the whiteout as well as the directory,
> and all is well.

Ugh. Having the kernel interpret magic directory entries is just evil.
Having the kernel magically create and remove said entries on behalf of
the user ought to be punishable by death.

Why can't you use something like an xattr to label opaqueness (or
visibility!) instead?

Cheers,
  Trond

Re: [RFC] Privilege escalation in filesystems

[Josef Sipek]

On Wed, Aug 09, 2006 at 06:17:32PM -0400, Trond Myklebust wrote:
> On Wed, 2006-08-09 at 17:52 -0400, Josef Sipek wrote:
...
> > (fs/nfs/nfs4recover.c:nfs4_save_user)
> > current->fsuid = 0;
> > current->fsgid = 0;
> 
> This sort of thing can be defeated by selinux.

I was affraid of that.

> The right way to perform privileged operations is normally to give the
> task to a kernel thread that has the required privileges (for instance a
> work_queue like keventd).

This makes sense. So, I suppose it would make sense to have a per-mount or
per-superblock pdflush-like thread that gets instantiated on mount.

> Ugh. Having the kernel interpret magic directory entries is just evil.
> Having the kernel magically create and remove said entries on behalf of
> the user ought to be punishable by death.

I'd like to hear about anything that is as portable, but not as "evil" :)

> Why can't you use something like an xattr to label opaqueness (or
> visibility!) instead?

The goal is to have as few restrictions as possible - not every file system
supports xattr.

Josef "Jeff" Sipek.

-- 
Bus Error: passangers dumped.

Re: [RFC] Privilege escalation in filesystems

[Bryan Henderson]

>Much like NFS, at times Unionfs has to perform operations as another 
user.
>...
>If the foo is owned by someone else and we don't have write permission to
>it, we'll fail to remove the opaque whiteout from foo (.wh.__dir_opaque),
>which would in turn prevent us from removing foo itself. If we become a
>superuser temporarily, we can remove the whiteout as well as the 
directory,
>and all is well.

What you're describing is not a need to perform operations as another 
user, but a need to perform them with DAC_OVERRIDE capability.  In Linux, 
having uid 0 buys you nothing but access to files owned by uid 0.

NFS server code, on the other hand, does have a need to become another 
user.

--
Bryan Henderson                     IBM Almaden Research Center
San Jose CA                         Filesystems

Re: [RFC] Privilege escalation in filesystems

[Josef Sipek]

On Thu, Aug 10, 2006 at 11:06:48AM -0700, Bryan Henderson wrote:
> >Much like NFS, at times Unionfs has to perform operations as another 
> user.
> >...
> >If the foo is owned by someone else and we don't have write permission to
> >it, we'll fail to remove the opaque whiteout from foo (.wh.__dir_opaque),
> >which would in turn prevent us from removing foo itself. If we become a
> >superuser temporarily, we can remove the whiteout as well as the 
> directory,
> >and all is well.
> 
> What you're describing is not a need to perform operations as another 
> user, but a need to perform them with DAC_OVERRIDE capability.

Thanks! I'll look into it.

Josef "Jeff" Sipek.

-- 
Penguin : Linux version 2.4.20-46.9.legacysmp on an i686 machine (2785.28 BogoMips).

Re: [RFC] Privilege escalation in filesystems

[Trond Myklebust]

On Thu, 2006-08-10 at 11:06 -0700, Bryan Henderson wrote:

> What you're describing is not a need to perform operations as another 
> user, but a need to perform them with DAC_OVERRIDE capability.  In Linux, 
> having uid 0 buys you nothing but access to files owned by uid 0.

Sorry, but CAP_DAC_OVERRIDE can, and usually will, be overridden in a
typical selinux environment. That is precisely why we had to abandon
using it for privileged operations such as binding a socket to a
reserved port in the SUNRPC layer in the early 2.6.x days.

Josef, if you really need to do this hidden directory creation (which is
also something which is not supported by all filesystems, BTW - remember
FAT and its 8+3 filenames?) then why not use that as a flag to signal
that the directory is visible to unionfs rather than have it signal
invisibility?
Then leave the whole issue of whether or not to set it to the user.

Cheers,
   Trond

Re: [RFC] Privilege escalation in filesystems

[Josef Sipek]

On Thu, Aug 10, 2006 at 03:45:19PM -0400, Trond Myklebust wrote:
> On Thu, 2006-08-10 at 11:06 -0700, Bryan Henderson wrote:
> 
> > What you're describing is not a need to perform operations as another 
> > user, but a need to perform them with DAC_OVERRIDE capability.  In Linux, 
> > having uid 0 buys you nothing but access to files owned by uid 0.
> 
> Sorry, but CAP_DAC_OVERRIDE can, and usually will, be overridden in a
> typical selinux environment.

Hrm.

> Josef, if you really need to do this hidden directory creation (which is
> also something which is not supported by all filesystems, BTW - remember
> FAT and its 8+3 filenames?

I know. But when you look at the number of file systems that have such silly
restriction, and compare it to say xattr availability (not to mention the
fact that you can have a file system which has xattr code, but it was
compiled without it) what's more likely to be a problem?

> ) then why not use that as a flag to signal that the directory is visible
> to unionfs rather than have it signal invisibility?  Then leave the whole
> issue of whether or not to set it to the user.

If I understand this correctly, you are suggesting inverting the meaning? It
is not so much of a (in)visibility flag as a opaque vs. translucent flag. It
seems like this would waste many inodes, but I'll keep it in mind.

Josef "Jeff" Sipek.

-- 
Reality is merely an illusion, albeit a very persistent one.
		- Albert Einstein