shared credentials with vfs snapshotting

shared credentials with vfs snapshotting

Post by David C. Hanse » Fri, 25 Oct 2002 22:20:13



This patch combines the ideas from two others:  Dave McCracken's
combination of task credentials into a single structure which is
shared between threads:
http://marc.theaimsgroup.com/?t=102830918300009&r=1&w=2
And Trond Myklebust's snapshotting of the vfs-specific parts of
the cred structure which are passed down into vfs and are strictly
copy-on-write.
http://marc.theaimsgroup.com/?t=103081191900001&r=1&w=2
http://marc.theaimsgroup.com/?t=103074984200004&r=1&w=2
http://www.fys.uio.no/~trondmy/src/2.5.32-alpha

Implementing the appearance of shared credentials to userspace requires
large amounts of code to be added in the threading libraries.  The
addition of code here is reasonalbly small.  

This patch is by no means complete or correct.  It completely ignores
the credential sharing flag for now.  It is just here to demonstrate the
combination of the two ideas.  Please don't go applying it to anything
;)

I think that the core of what is needed is in the attached patch.  Most
of what is left can be accomplished with s/->uid/->cred->uid/ and
s/->fsuid/->cred->vfscred->uid/

And, as Trond says:

Quote:> Unfortunately there's still a bit more to do. I need to get
> the file creation ops (i_op->create()/symlink()/mknod()/mkdir()) to
> take a vfs_cred* argument. If not, you risk having the
> inode->i_uid/i_gid set to values that differ from the ones checked by
> the calls to ->permission().

--
Dave Hansen

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

shared credentials with vfs snapshotting

Post by David C. Hanse » Fri, 25 Oct 2002 22:30:14


Oh yeah, the code!
--
Dave Hansen

  cred-sharing-snapshotting-2.5.44-0.patch
24K Download

 
 
 

1. Allow tasks to share credentials

I worry about the lack of locking here.

Maybe it's the right thing to do, I don't really know.

But I _know_, for example, that this is just a horrid security hole the
way it is now - the execve() path doesn't create a unique "cred"
structure, so if you execve() a suid binary from a CLONE_CRED thread, the
other threads get the suid'ness and can do whatever they want.

At the very least, it should disallow suid exec's when

        atomic_read(&current->cred->count) > 1

which is the same approach we do wrt other shared state (ie disallow a
CLONE_FILES thing from doing a suid execve etc).

The alternative is to just allocate a new cred structure on execve.

As-is this patch is way way too dangerous. You can trivially create a root
hole by doing

        if (!clone(CLONE_CRED)) {
                execve("su");
                exit(1);
        }

        ..this thread now also got root..

You may be right. I don't see any huge reason for it, but see above on
other fundamental problems.

                Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2. IDE RAID card or software RAID ?

3. Fourth attempt at a shared credentials patch

4. Weird problem, only one port, 80, is blocked.

5. JFS2 AIX 5.2 snapshot: consistent snapshot for multiple file systems

6. need help with setting up a virtual pop server

7. Snapshot of shared page tables

8. Installing linux on WinNT machine

9. Changing the root master's credential (NIS+)

10. Cannot set process credentials

11. (resend) credentials for 2.5.23

12. Encryption credentials

13. How do you validate user credentials?