linux-kernel - Re: Thoughts on credential switching

lists.openwall.net		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 linux-cve-announce 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 <luto@...capital.net>
To:	"Theodore Ts'o" <tytso@....edu>, Jeff Layton <jlayton@...hat.com>,
	Andy Lutomirski <luto@...capital.net>,
	Jim Lieb <jlieb@...asas.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	LSM List <linux-security-module@...r.kernel.org>,
	"Serge E. Hallyn" <serge@...onical.com>,
	Kees Cook <keescook@...omium.org>,
	Linux FS Devel <linux-fsdevel@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	bfields@...hat.com
Subject: Re: Thoughts on credential switching

On Sun, Mar 30, 2014 at 6:03 AM, Theodore Ts'o <tytso@....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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/