You are viewing a plain text version of this content. The canonical link for it is here.
Posted to hdfs-dev@hadoop.apache.org by lei liu <li...@gmail.com> on 2013/11/13 04:30:55 UTC
block access token
When client read block from DataNode, the block access token is used for
authorization on DataNode. But if the block access token is stolen by
impostor, the impostor can read the block,
I think this is one security hole.
I think we can use the replay cache mechanism in Kerberos to resolve the
question, example below explaining:
The possibility exists for an impostor to simultaneously steal both the
ticket and the authenticator and use them during the 2 minutes the
authenticator is valid. This is very difficult but not impossible. To solve
this problem with Kerberos 5, Replay Cache has been introduced. In
application servers (but also in TGS), there exists the capacity to
remember authenticators which have arrived within the last 2 minutes, and
to reject them if they are replicas. With this the problem is resolved as
long as the impostor is not smart enough to copy the ticket and
authenticator and make them arrive at the application server before the
legitimate request arrives. This really would be a hoax, since the
authentic user would be rejected while the impostor would have access to
the service.
Thanks,
LiuLei
Re: block access token
Posted by lei liu <li...@gmail.com>.
Hi Luke,
Can I set "dfs.block.access.token.lifetime" to two minutes?
2013/11/18 lei liu <li...@gmail.com>
> Thanks Luke for your reply.
>
> The life time of block access token is ten hours, whether we should
> change two minutes? I think the shorter the life time of the token, token less
> likely to be stolen.
>
>
> 2013/11/14 Luke Lu <ll...@apache.org>
>
>> Block access token is only valid for a short period of time, as the NN/DN
>> shared secrets are rolled periodically. As long as you cannot steal block
>> token easily (besides using zero-day bugs), there is really no security
>> hole here (by design). If you know of a way to steal block tokens without
>> root access, let us know.
>>
>>
>> On Tue, Nov 12, 2013 at 7:30 PM, lei liu <li...@gmail.com> wrote:
>>
>> > When client read block from DataNode, the block access token is used for
>> > authorization on DataNode. But if the block access token is stolen by
>> > impostor, the impostor can read the block,
>> > I think this is one security hole.
>> >
>> > I think we can use the replay cache mechanism in Kerberos to resolve the
>> > question, example below explaining:
>> >
>> > The possibility exists for an impostor to simultaneously steal both the
>> > ticket and the authenticator and use them during the 2 minutes the
>> > authenticator is valid. This is very difficult but not impossible. To
>> solve
>> > this problem with Kerberos 5, Replay Cache has been introduced. In
>> > application servers (but also in TGS), there exists the capacity to
>> > remember authenticators which have arrived within the last 2 minutes,
>> and
>> > to reject them if they are replicas. With this the problem is resolved
>> as
>> > long as the impostor is not smart enough to copy the ticket and
>> > authenticator and make them arrive at the application server before the
>> > legitimate request arrives. This really would be a hoax, since the
>> > authentic user would be rejected while the impostor would have access to
>> > the service.
>> >
>> >
>> > Thanks,
>> >
>> > LiuLei
>> >
>>
>
>
Re: block access token
Posted by lei liu <li...@gmail.com>.
Thanks Luke for your reply.
The life time of block access token is ten hours, whether we should change two
minutes? I think the shorter the life time of the token, token less likely to
be stolen.
2013/11/14 Luke Lu <ll...@apache.org>
> Block access token is only valid for a short period of time, as the NN/DN
> shared secrets are rolled periodically. As long as you cannot steal block
> token easily (besides using zero-day bugs), there is really no security
> hole here (by design). If you know of a way to steal block tokens without
> root access, let us know.
>
>
> On Tue, Nov 12, 2013 at 7:30 PM, lei liu <li...@gmail.com> wrote:
>
> > When client read block from DataNode, the block access token is used for
> > authorization on DataNode. But if the block access token is stolen by
> > impostor, the impostor can read the block,
> > I think this is one security hole.
> >
> > I think we can use the replay cache mechanism in Kerberos to resolve the
> > question, example below explaining:
> >
> > The possibility exists for an impostor to simultaneously steal both the
> > ticket and the authenticator and use them during the 2 minutes the
> > authenticator is valid. This is very difficult but not impossible. To
> solve
> > this problem with Kerberos 5, Replay Cache has been introduced. In
> > application servers (but also in TGS), there exists the capacity to
> > remember authenticators which have arrived within the last 2 minutes, and
> > to reject them if they are replicas. With this the problem is resolved as
> > long as the impostor is not smart enough to copy the ticket and
> > authenticator and make them arrive at the application server before the
> > legitimate request arrives. This really would be a hoax, since the
> > authentic user would be rejected while the impostor would have access to
> > the service.
> >
> >
> > Thanks,
> >
> > LiuLei
> >
>
Re: block access token
Posted by Luke Lu <ll...@apache.org>.
Block access token is only valid for a short period of time, as the NN/DN
shared secrets are rolled periodically. As long as you cannot steal block
token easily (besides using zero-day bugs), there is really no security
hole here (by design). If you know of a way to steal block tokens without
root access, let us know.
On Tue, Nov 12, 2013 at 7:30 PM, lei liu <li...@gmail.com> wrote:
> When client read block from DataNode, the block access token is used for
> authorization on DataNode. But if the block access token is stolen by
> impostor, the impostor can read the block,
> I think this is one security hole.
>
> I think we can use the replay cache mechanism in Kerberos to resolve the
> question, example below explaining:
>
> The possibility exists for an impostor to simultaneously steal both the
> ticket and the authenticator and use them during the 2 minutes the
> authenticator is valid. This is very difficult but not impossible. To solve
> this problem with Kerberos 5, Replay Cache has been introduced. In
> application servers (but also in TGS), there exists the capacity to
> remember authenticators which have arrived within the last 2 minutes, and
> to reject them if they are replicas. With this the problem is resolved as
> long as the impostor is not smart enough to copy the ticket and
> authenticator and make them arrive at the application server before the
> legitimate request arrives. This really would be a hoax, since the
> authentic user would be rejected while the impostor would have access to
> the service.
>
>
> Thanks,
>
> LiuLei
>