(In reply to Murray McAllister from comment #0)
> After performing a cluster operation with ccs and the correct password
> supplied, css ignored the password for subsequent operations. This could
> allow an attacker to perform cluster operations via css without knowing the
> correct password.

Please see bug 1084991, comment 4 and bug 1084991, comment 5 for more details as yous summary is not precise.

Hey guys, let's not exaggerate an importance of one particular view.
In fact we are talking about the intentional design ... just like
protected web site doesn't want you to re-enter password upon each
request.  The only possible problem is that the analogy to "session"
is not limited in time (perhaps there is a limitation by the window
in which the certificate is valid) -- administrator of the cluster
nodes can (selectively or not) purge the recognized certificates
as tracked by particular ricci instances.

So the counterproposal is that ccs will spit out "already authenticated,
password ignored" to make it clear what's going on for calm down those
expecting more granular authentication flow.

Also important is to realize that the "state" allowing one to
authenticate without password (state = the once password-proved
certificate, really) is the private property of the user who did
it, stored under her home directory.  So yes, compromising user
can lead to privileges to clusters the user in question had ability
to manage, but the same can be said about SSH keys, etc.

Overall, we are talking about design/misuse boundary, but the common
practices in other software pieces indicates there's no more risk
than usual.

[comment 3]:

> The only possible problem is that the analogy to "session"
> is not limited in time (perhaps there is a limitation by the window
> in which the certificate is valid)

Radek tested the enforcement of certificate validity window with
negative findings: moving system clock either before or after the
boundaries will not change anything in the behavior.
This is to GSS' delight, less so to security nitpickers'.


[comment 5]:

> My understanding:
> 
> 1 The password is merely used to authenticate a cert.
> 2 The authenticated cert is what is actually used to get access.
> 3 As a result of 2: if you enter an invalid password after entering
> a valid one at some point in the past, your access is still granted.

Correct.


Re idea of "examine password correctness each time it is provided":
As this action is always delegated to the remote agent (ricci) instance
(as the password is system-wide password of ricci user on that very
system and hence cannot be performed locally) it would mean several
things:

1. sending the plaintext password over the semi-safe wire
   (SSL/TLS, but DNS and other attacks, ricci's certificate
   or its fingerprint is not expected to be a priori preshared
   in a safe manner) needlessly if certificate is all getting
   you in
2. communication/time overhead (somewhat negligible, for posterity)
   just for "incorrect password, falling back on previous cert,
   cert authenticated" message


I agree to rejecting the CVE.  František, do you agree?  Is there
anything requiring more explanation?


My full counterproposal so far is:

- try certificate authentication first, if it succeeds AND the password
  was provided, print a variant of

> Note: already authenticated, password ignored.

  as per [comment 3]

- add "-1", "--one-shot" command-line switch meaning that the password
  provided is meant to authorize only the action(s) specified in the rest
  of command line options/arguments.  In such case, the certificate used
  (whether it was already recognized/authorized or not) will be forgotten/
  de-authorized as the last step within the sent batch of tasks to perform

  - this may sound cumbersome, but it is doable right now, without a need
    to modify ricci side in any way

  - this would achieve the behavior as expected by the reporter


Thoughts?

I sort of agree with counter-proposal.

Above note 'Note: already authenticated, password ignored.' seems to me as good compromise of high-level and ricci micro-level point of views.
This addresses the Bug 1084991 case a].

I sort of agree on one time authentication mode although I find suggested parameters not well named (my proposal would be --one-time-authentication or --one-time-limited-authentication)

on the other hand I think dropping certificates and forcing re-authentication is still needed for Bug 1084991 case b] when ricci password changed. In this particular case chage should be able to provide such information. This in fact matches your 'session' analogy and highlights similar case to certification expiration.

I agree to solve this as part of Bug 1084991 not this CVE.

Can I publicly REJECT this CVE?

I have no issue rejecting this CVE ID.