On Sun, Mar 30, 2014 at 6:03 AM, Theodore Ts'o <ty...@mit.edu> wrote: > On Thu, Mar 27, 2014 at 07:08:02AM -0700, Jeff Layton wrote: >> I had some time to think about this last night... >> >> While using a fd to pass around credentials is convenient, the danger >> is that it's pretty opaque. You have a fd that you know has creds >> attached to it, but it's hard to be certain what is going to change. > > I don't think that's a particularly tough problem. In general, the fd > isn't something that you would want to pass around, and so the process > which generated it will know exactly what it contained. > >> Perhaps we can use the flags field for that. So, assuming we have a fd >> with the creds attached, we could do something like: >> >> err = switch_creds(fd, SC_FSUID|SC_FSGID|SC_GROUPS); >> >> ...then the switch_creds syscall could be set up to fail if the new >> credentials had other fields that didn't match those in the current >> task credentials. So if (for instance) the cred->euid were >> different between the two, the above could fail with -EINVAL or >> something. > > Huh? The whole *point* is that the creds value will be different, of > course they won't match! I would think this would be over > complicating the interface. > > > A couple of other things. What I would suggest is that we create a > few new fd flags, to join FD_CLOEXEC: > > FD_NOPROCFS disallow being able to open the inode via /proc/<pid>/fd > (but in the case of a creds fd, for bonus points, the > target of the pseudo-symlink could be something like: > "uid: 15806 gid: 100: grps: 27, 50" to aid in debugging > a userspace file server). This also answers Jeff's concern > if for some reason --- I don't know how --- a process > doesn't know what the contents of the creds fd that > it created itself. > > FD_NOPASSFD disallow being able to pass the fd via a unix domain socket > > FD_LOCKFLAGS if this bit is set, disallow any further changes of > FD_CLOEXEC, > FD_NOPROCFS, FD_NOPASSFD, and FD_LOCKFLAGS flags. > > Some of the functionality requested by the folks suggesting the "SEAL" > API would also be covered by these fd flags. > > In order to solve some potential race concerns, a credsfd must be > created with FD_CLOEXEC and FD_NOPROCFS enabled.
It might be nice to try to coordinate this with the Capsicum people, who are doing something along these lines. They even have tentative Linux patches. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
