lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sun, 30 Mar 2014 11:56:08 -0700
From:	Andy Lutomirski <>
To:	"Theodore Ts'o" <>, Jeff Layton <>,
	Andy Lutomirski <>,
	Jim Lieb <>,
	"Eric W. Biederman" <>,
	LSM List <>,
	"Serge E. Hallyn" <>,
	Kees Cook <>,
	Linux FS Devel <>,
	"" <>,
Subject: Re: Thoughts on credential switching

On Sun, Mar 30, 2014 at 6:03 AM, Theodore Ts'o <> 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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists