Re: [RFC] Handle ACLs that are neither denied nor allowed

On 23/03/2012 4:21 a.m., Alex Rousskov wrote:
> On 03/22/2012 01:10 AM, Alex Rousskov wrote:
>
>>>> IMHO, if authentication is involved, the only sane option is to follow
>>>> this pattern:
>>>>
>>>> 1a. Authenticate (may require several HTTP transactions).
>>>>
>>>> 1b. Iff authenticated user is authorized to access Squid, continue.
>>>> Otherwise, deny further access.
>>>>
>>>> 2. Use authenticated user credentials as needed.
>>>> No authentication can be triggered at this stage.
>>>> Credentials cannot become invalid or stale here.
>>> They *can* become stale.
>> In my proposal, the authenticated and accepted credentials cannot become
>> stale in the transaction context/lifetime. They simply do not have any
>> expiration date from this design point of view. Once accepted for a
>> transaction, they stay valid for that transaction until the transaction
>> is over.
>>
>>
>>> But we may use them anyway when there is no
>>> security risk. When there is security involved we must not use them
>>> until revalidation. That is the point of EXPIRED_OK. It means we are
>>> waiting an async helper lookup to re-validate them, but at last
>>> validation they were okay. The access list context is where the
>>> information about security-risk is implicit/known.
>> In my model, this complexity (and the need to determine the level of
>> security risk) simply does not exist (because I see no reason to make
>> credentials state variable during a single transaction lifetime).
>>
>>
>>> Consider: Admin closes a users account and removed them from the system.
>>> Just before that the user opened a CONNECT and starts using it for a
>>> week non-stop. All of the bumped requests are authorized under the
>>> expired credentials?
>> This is not a very good example because individual bumped requests
>> inside a CONNECT tunnel are normally not authenticated (the CONNECT
>> tunnel itself is). So, under normal circumstances, the already
>> authorized tunnel will remain authorized (and so will any transactions
>> inside it, bumped or not).
>>
>> If this is not desirable, we can add a feature to forcefully terminate
>> in-progress transactions (and tunnels) under some conditions, but such
>> termination will not be put inside ssl_bump, tcp_outgoing_tos, and
>> similar option handling code that should have nothing to do with
>> transaction lifetime and authentication/authorization.
>
> I just realized that the above answer may be misleading. The proposed
> design gives better options than my description above may apply. There
> are two separate aspects here and I did not make it clear:
>
> * The above talks about authentication. Authentication information for a
> given transaction or tunnel does not change once set (and does not have
> a freshness status or expiration ability). Bob's tunnel is Bob's tunnel
> forever. It will never become Alice' tunnel. All requests inside Bob's
> tunnel are Bob's requests, of course.
>
> * However, access control is a separate issue. Http_access and similar
> access control knobs may apply to bumped requests inside tunnels and are
> checked at the time of the request. Thus, if Bob's account is deleted,
> his access to Squid can be blocked using http_access (normally without
> re-authentication because we should not authenticate bumped requests).
> No additional options are needed for this.

This bites to the heart of the issue. Should all of Bobs access be cut
immediately when his credentials expire or not?

The current authentication cases are:

  * NTLM and Negotiate authenticate the TCP connection. Credentials do
not detatch until the keep-alive/pinned/persistent connection is closed.
Validation can only be done once.

  * Digest nonce becomes stale with every N milliseconds and needs
revalidating each request.

  * Bearer access_token becomes invalid on a timeout after N
milliseconds from allocation, authorization can be revoked midway
through a transaction.

  * Basic credentials are valid only for one request.

  * side-band credentials from external ACL can be revoked and replaced
(bob becomes alice) on any ACL test.

  * REQMOD adaptation can revoke and replace (bob becomes alice)
credentials.

  * SSL certificate credentials authenticate the connection. Validation
can only be done once.

  * SSL-bump cannot authenticate aand must use credentials from CONNECT
request (if any). Validation can only be done on the CONNECT.

That is the requirements Squid has to meet.

Solution?
- pull Digest/Bearer/Basic creds from request and check validity
per-request.
- pull NTLM/Negotiate creds from connection and check validity only on
handshake request.
- pull SSL certificate creds from connection and check validity only on
handshake.
- pull SSL-bumped creds from connection and check validity never.
- pull external ACL creds from request and check validity never.

adaptation is the main problem. Do we check credentials validity in
http_access only? or in both http_access AND adapted_http_access?

external ACL is a similar problem. Can we assume the script writer knows
best and replace any request credentials with those given by the ACL?

can we go so far as to trust both external ACL helpers and whatever
adaptation system are in use and not bother to validate credentials
received from there *at all*?

Amos
Received on Fri Mar 23 2012 - 10:27:32 MDT