Allow user spoofing in insecure clusters?

[Todd Lipcon <to...@cloudera.com>]

Hey folks,

I had the occasion yesterday of trying to run an admin tool from my laptop
(as user 'todd') against an insecure cluster (running as user 'kudu'). The
cluster was rejecting me because I wasn't in the admin/service ACLs, which
was somewhat annoying.

I worked around the problem by locally hacking my copy of user.cc to ignore
my actual username and just return "kudu" :)

I think it's good that we have authorization enabled even in insecure
clusters, since it reduces test variables and prevents "accidental" usage
of higher privileges. So, I don't think we should disable the above
behavior.

That said, it's inconvenient to have to recompile Kudu to spoof a user
against an insecure cluster. Given that it's already easy to spoof for a
malicious user, does anyone have an objection to making it easier for
non-malicious users to spoof by respecting some environment variable like
KUDU_USER or KUDU_INSECURE_USER or KUDU_SPOOF_USER or somesuch?

-Todd
-- 
Todd Lipcon
Software Engineer, Cloudera

Re: Allow user spoofing in insecure clusters?

[Adar Dembo <ad...@cloudera.com>]

Just to be clear, the usual "sudo -u kudu ..." workaround doesn't
apply here because there's no 'kudu' UNIX user on your laptop, right?

Also, your suggestion is for _client_ applications (i.e. the 'kudu'
CLI) to look for a KUDU_USER env variable, right? If so I'm +1.


On Wed, Jun 21, 2017 at 10:52 AM, Todd Lipcon <to...@cloudera.com> wrote:
> Hey folks,
>
> I had the occasion yesterday of trying to run an admin tool from my laptop
> (as user 'todd') against an insecure cluster (running as user 'kudu'). The
> cluster was rejecting me because I wasn't in the admin/service ACLs, which
> was somewhat annoying.
>
> I worked around the problem by locally hacking my copy of user.cc to ignore
> my actual username and just return "kudu" :)
>
> I think it's good that we have authorization enabled even in insecure
> clusters, since it reduces test variables and prevents "accidental" usage
> of higher privileges. So, I don't think we should disable the above
> behavior.
>
> That said, it's inconvenient to have to recompile Kudu to spoof a user
> against an insecure cluster. Given that it's already easy to spoof for a
> malicious user, does anyone have an objection to making it easier for
> non-malicious users to spoof by respecting some environment variable like
> KUDU_USER or KUDU_INSECURE_USER or KUDU_SPOOF_USER or somesuch?
>
> -Todd
> --
> Todd Lipcon
> Software Engineer, Cloudera

Re: Allow user spoofing in insecure clusters?

[Mike Percy <mp...@apache.org>]

At the risk of sounding snarky (not trying to) I really don't understand
our current security model when Kerberos is turned off. Validating
authentication and authorization rules when user identity is easily
spoofable is annoying and also not secure (because, well, security is
turned off). Case in point, as alluded to by Todd, is having to type "sudo
-u kudu kudu cluster ksck" to run ksck as of Kudu 1.4. It's silly.

AFAICT, authentication enforcement when Kerberos is disabled serves no
useful purpose. In non-secure mode Kudu should simply skip all kinds of
authn and authz. For people who need the current rules (I can't see why
they would) we could add a flag to enable it (maybe called
--believe-remote-clients-without-auth).

My 2c,
Mike

On Wed, Jun 21, 2017 at 1:28 PM, Alexey Serbin <as...@cloudera.com> wrote:

> I also think it's better to not introduce environment-controlled behavior
> into the Kudu C++ client library itself.  I'm in favor of Dan's proposal.
>
> If I remember correctly, there was an idea to implement some sort of
> configuration for the client library via config file.  That's a separate
> theme on its own, but if it's going to be implemented, keeping off the
> environment-controlled behavior from the client library makes more sense in
> that context as well.  It also makes more sense to avoid introducing
> environment-controlled behavior if we want to keep the C++ and the Java
> client parity to some extent.
>
> Having the explicit run-time flag for the CLI tool might be even a better
> option.  And it would be nice if that worked for the Kerberized setup as
> well (maybe, in the future).
>
>
> Best regards,
>
> Alexey
>
>
>
> On 6/21/17 11:06 AM, Dan Burkert wrote:
>
>> I'm in favor of providing an easy to use workaround for this case, but I'd
>> like to see it implemented a bit differently.  I think the user name
>> should
>> be an option in the Kudu client builder (alongside e.g.
>> import_authentication_credentials
>> <https://github.com/cloudera/kudu/blob/master/src/kudu/clien
>> t/client.h#L240>),
>> and the application (in this case the kudu tool) would be responsible for
>> reading an environment variable and setting it appropriately (or perhaps
>> via a gflag).  Same effect in the end, but I don't think pure libraries
>> should be reading things from the environment.
>>
>> All that being said, I'd also be in favor of KUDU_USER over the longer
>> variants, since changing the username is not inherently insecure; the
>> 'source' of the insecurity is the cluster's configuration, not the client
>> configuration.
>>
>> - Dan
>>
>> On Wed, Jun 21, 2017 at 10:52 AM, Todd Lipcon <to...@cloudera.com> wrote:
>>
>> Hey folks,
>>>
>>> I had the occasion yesterday of trying to run an admin tool from my
>>> laptop
>>> (as user 'todd') against an insecure cluster (running as user 'kudu').
>>> The
>>> cluster was rejecting me because I wasn't in the admin/service ACLs,
>>> which
>>> was somewhat annoying.
>>>
>>> I worked around the problem by locally hacking my copy of user.cc to
>>> ignore
>>> my actual username and just return "kudu" :)
>>>
>>> I think it's good that we have authorization enabled even in insecure
>>> clusters, since it reduces test variables and prevents "accidental" usage
>>> of higher privileges. So, I don't think we should disable the above
>>> behavior.
>>>
>>> That said, it's inconvenient to have to recompile Kudu to spoof a user
>>> against an insecure cluster. Given that it's already easy to spoof for a
>>> malicious user, does anyone have an objection to making it easier for
>>> non-malicious users to spoof by respecting some environment variable like
>>> KUDU_USER or KUDU_INSECURE_USER or KUDU_SPOOF_USER or somesuch?
>>>
>>> -Todd
>>> --
>>> Todd Lipcon
>>> Software Engineer, Cloudera
>>>
>>>
>

Re: Allow user spoofing in insecure clusters?

[Alexey Serbin <as...@cloudera.com>]

I also think it's better to not introduce environment-controlled 
behavior into the Kudu C++ client library itself.  I'm in favor of Dan's 
proposal.

If I remember correctly, there was an idea to implement some sort of 
configuration for the client library via config file.  That's a separate 
theme on its own, but if it's going to be implemented, keeping off the 
environment-controlled behavior from the client library makes more sense 
in that context as well.  It also makes more sense to avoid introducing 
environment-controlled behavior if we want to keep the C++ and the Java 
client parity to some extent.

Having the explicit run-time flag for the CLI tool might be even a 
better option.  And it would be nice if that worked for the Kerberized 
setup as well (maybe, in the future).


Best regards,

Alexey


On 6/21/17 11:06 AM, Dan Burkert wrote:
> I'm in favor of providing an easy to use workaround for this case, but I'd
> like to see it implemented a bit differently.  I think the user name should
> be an option in the Kudu client builder (alongside e.g.
> import_authentication_credentials
> <https://github.com/cloudera/kudu/blob/master/src/kudu/client/client.h#L240>),
> and the application (in this case the kudu tool) would be responsible for
> reading an environment variable and setting it appropriately (or perhaps
> via a gflag).  Same effect in the end, but I don't think pure libraries
> should be reading things from the environment.
>
> All that being said, I'd also be in favor of KUDU_USER over the longer
> variants, since changing the username is not inherently insecure; the
> 'source' of the insecurity is the cluster's configuration, not the client
> configuration.
>
> - Dan
>
> On Wed, Jun 21, 2017 at 10:52 AM, Todd Lipcon <to...@cloudera.com> wrote:
>
>> Hey folks,
>>
>> I had the occasion yesterday of trying to run an admin tool from my laptop
>> (as user 'todd') against an insecure cluster (running as user 'kudu'). The
>> cluster was rejecting me because I wasn't in the admin/service ACLs, which
>> was somewhat annoying.
>>
>> I worked around the problem by locally hacking my copy of user.cc to ignore
>> my actual username and just return "kudu" :)
>>
>> I think it's good that we have authorization enabled even in insecure
>> clusters, since it reduces test variables and prevents "accidental" usage
>> of higher privileges. So, I don't think we should disable the above
>> behavior.
>>
>> That said, it's inconvenient to have to recompile Kudu to spoof a user
>> against an insecure cluster. Given that it's already easy to spoof for a
>> malicious user, does anyone have an objection to making it easier for
>> non-malicious users to spoof by respecting some environment variable like
>> KUDU_USER or KUDU_INSECURE_USER or KUDU_SPOOF_USER or somesuch?
>>
>> -Todd
>> --
>> Todd Lipcon
>> Software Engineer, Cloudera
>>

Re: Allow user spoofing in insecure clusters?

[Dan Burkert <da...@apache.org>]

I'm in favor of providing an easy to use workaround for this case, but I'd
like to see it implemented a bit differently.  I think the user name should
be an option in the Kudu client builder (alongside e.g.
import_authentication_credentials
<https://github.com/cloudera/kudu/blob/master/src/kudu/client/client.h#L240>),
and the application (in this case the kudu tool) would be responsible for
reading an environment variable and setting it appropriately (or perhaps
via a gflag).  Same effect in the end, but I don't think pure libraries
should be reading things from the environment.

All that being said, I'd also be in favor of KUDU_USER over the longer
variants, since changing the username is not inherently insecure; the
'source' of the insecurity is the cluster's configuration, not the client
configuration.

- Dan

On Wed, Jun 21, 2017 at 10:52 AM, Todd Lipcon <to...@cloudera.com> wrote:

> Hey folks,
>
> I had the occasion yesterday of trying to run an admin tool from my laptop
> (as user 'todd') against an insecure cluster (running as user 'kudu'). The
> cluster was rejecting me because I wasn't in the admin/service ACLs, which
> was somewhat annoying.
>
> I worked around the problem by locally hacking my copy of user.cc to ignore
> my actual username and just return "kudu" :)
>
> I think it's good that we have authorization enabled even in insecure
> clusters, since it reduces test variables and prevents "accidental" usage
> of higher privileges. So, I don't think we should disable the above
> behavior.
>
> That said, it's inconvenient to have to recompile Kudu to spoof a user
> against an insecure cluster. Given that it's already easy to spoof for a
> malicious user, does anyone have an objection to making it easier for
> non-malicious users to spoof by respecting some environment variable like
> KUDU_USER or KUDU_INSECURE_USER or KUDU_SPOOF_USER or somesuch?
>
> -Todd
> --
> Todd Lipcon
> Software Engineer, Cloudera
>

Re: Allow user spoofing in insecure clusters?

[Brock Noland <br...@phdata.io>]

+1 - really useful in Hadoop for non-secure clusters.

On Wed, Jun 21, 2017 at 1:00 PM, Jean-Daniel Cryans <jd...@apache.org> wrote:
> +1, might as well allow it.
>
> On Wed, Jun 21, 2017 at 10:52 AM, Todd Lipcon <to...@cloudera.com> wrote:
>
>> Hey folks,
>>
>> I had the occasion yesterday of trying to run an admin tool from my laptop
>> (as user 'todd') against an insecure cluster (running as user 'kudu'). The
>> cluster was rejecting me because I wasn't in the admin/service ACLs, which
>> was somewhat annoying.
>>
>> I worked around the problem by locally hacking my copy of user.cc to ignore
>> my actual username and just return "kudu" :)
>>
>> I think it's good that we have authorization enabled even in insecure
>> clusters, since it reduces test variables and prevents "accidental" usage
>> of higher privileges. So, I don't think we should disable the above
>> behavior.
>>
>> That said, it's inconvenient to have to recompile Kudu to spoof a user
>> against an insecure cluster. Given that it's already easy to spoof for a
>> malicious user, does anyone have an objection to making it easier for
>> non-malicious users to spoof by respecting some environment variable like
>> KUDU_USER or KUDU_INSECURE_USER or KUDU_SPOOF_USER or somesuch?
>>
>> -Todd
>> --
>> Todd Lipcon
>> Software Engineer, Cloudera
>>

Re: Allow user spoofing in insecure clusters?

[Jean-Daniel Cryans <jd...@apache.org>]

+1, might as well allow it.

On Wed, Jun 21, 2017 at 10:52 AM, Todd Lipcon <to...@cloudera.com> wrote:

> Hey folks,
>
> I had the occasion yesterday of trying to run an admin tool from my laptop
> (as user 'todd') against an insecure cluster (running as user 'kudu'). The
> cluster was rejecting me because I wasn't in the admin/service ACLs, which
> was somewhat annoying.
>
> I worked around the problem by locally hacking my copy of user.cc to ignore
> my actual username and just return "kudu" :)
>
> I think it's good that we have authorization enabled even in insecure
> clusters, since it reduces test variables and prevents "accidental" usage
> of higher privileges. So, I don't think we should disable the above
> behavior.
>
> That said, it's inconvenient to have to recompile Kudu to spoof a user
> against an insecure cluster. Given that it's already easy to spoof for a
> malicious user, does anyone have an objection to making it easier for
> non-malicious users to spoof by respecting some environment variable like
> KUDU_USER or KUDU_INSECURE_USER or KUDU_SPOOF_USER or somesuch?
>
> -Todd
> --
> Todd Lipcon
> Software Engineer, Cloudera
>