linux-kernel - Re: [PATCH review 48/85] sunrpc: Update gss uid to security context mapping.

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]

Message-ID: <87fw0zrk0e.fsf@xmission.com>
Date:	Wed, 13 Feb 2013 13:17:37 -0800
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	"J. Bruce Fields" <bfields@...ldses.org>
Cc:	linux-fsdevel@...r.kernel.org,
	Linux Containers <containers@...ts.linux-foundation.org>,
	linux-kernel@...r.kernel.org, "Serge E. Hallyn" <serge@...lyn.com>,
	Trond Myklebust <Trond.Myklebust@...app.com>
Subject: Re: [PATCH review 48/85] sunrpc: Update gss uid to security context mapping.

"J. Bruce Fields" <bfields@...ldses.org> writes:

> On Wed, Feb 13, 2013 at 09:51:37AM -0800, Eric W. Biederman wrote:
>> From: "Eric W. Biederman" <ebiederm@...ssion.com>
>> 
>> - Use from_kuid when generating the on the wire uid values.
>> - Use make_kuid when reading on the wire values.
>> 
>> In gss_encode_v0_msg, since the uid in gss_upcall_msg is now a kuid_t
>> generate the necessary uid_t value on the stack copy it into
>> gss_msg->databuf where it can safely live until the message is no
>> longer needed.
>
> Apologies, I haven't been following the user namespace work.
>
> If I understand correctly, you're expecting the id's seen in nfs
> protocol messages to be the same as the id's seen in the initial user
> namespace.
>
> Why is that right, and not, say, the user namespace in which the mount
> was originally performed?  (Just asking, I honestly haven't thought
> about it before.)

Actually my expectation is the user namespace was originally performed
in.  Currently nfs doesn't support being  mounted in anything other
than the initial user namespace.

> Also:
>
>> diff --git a/net/sunrpc/auth_gss/auth_gss.c b/net/sunrpc/auth_gss/auth_gss.c
>> index afbbcfb..a360067 100644
>> --- a/net/sunrpc/auth_gss/auth_gss.c
>> +++ b/net/sunrpc/auth_gss/auth_gss.c
>> @@ -395,8 +395,11 @@ gss_upcall_callback(struct rpc_task *task)
>>  
>>  static void gss_encode_v0_msg(struct gss_upcall_msg *gss_msg)
>>  {
>> -	gss_msg->msg.data = &gss_msg->uid;
>> -	gss_msg->msg.len = sizeof(gss_msg->uid);
>> +	uid_t uid = from_kuid(&init_user_ns, gss_msg->uid);
>> +	memcpy(gss_msg->databuf, &uid, sizeof(uid));
>> +	gss_msg->msg.data = gss_msg->databuf;
>> +	gss_msg->msg.len = sizeof(uid);
>> +	BUG_ON(sizeof(uid) > UPCALL_BUF_LEN);
>
> This message is going to gssd, not to the server.  Should it be encoded
> for whatever namespace gssd lives in?

Good basic question.  The immediate answer is that right now I only
support these things living in user namespace the filesystem was
mounted in, aka the initial user namespace.

There are a handful of things ioctls, and a quota call or two that I
will translate into the callers user namespace.  For network filesystems
and their specialized helpers it would be lossy and unnecessarily
complex to support arbitrary pieces living in different user namespaces.
Historically unix has had syncrhonized password databases to ensure even
multiple machines effectively had the same user namespace.

The really important step for me is to have the kernel using kuid_t and
kgid_t throughout and only converting when talking outside of the kernel
(disk, filesystem on disk data structures, network).

With that step I can enable user namespaces and the various filesystems.
And even if the filesystem itself is restricted to just one user
namespace, the users who read and write files on that filesystem won't
be.

A next step for the filesystems where this is interesting is to support
a user who is not the global root mounting the filesystem and having the
filesystem speak in ids in the user namespace that the filesystem was
mounted in.  That takes a little bit of connecting the dots of which
user namespace goes where, and it takes a little bit of confidence that
the kernel won't fall over if an evil server sends us deliberately bad
protocol messages.  I suspect at some point someone will want to figure
all of that out for nfs, certainly there has been work to figure that
out for network namespaces.

For now though I am happy to have kuid_t and kgid_t pushed down
everywhere they should be.

Eric
--
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/