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

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.

Hope this clarifies,

Alex.
Received on Thu Mar 22 2012 - 15:21:28 MDT