[EMAIL PROTECTED] (Chris Cowan) writes:
> 1. The -notify flag for bos.
> I wish this was called for all state changes of a Bos instance (and it
> passed the new state as an argument!). Right now, it only reports an
> instance going down!!! Anyway it's very easy to send a trap/alert when the
You can do this yourself by either adding the notifier to a bos
instance, or by writing simple (shell script, even) wrappers for the
processes you want to watch.
> 2. kpwvalid
>
> I wish this exit was performed at the server end, not the client end.
> Even though it has to be in the same directory as kpasswd, there's nothing
> to stop a clever user from circumventing the whole thing by
> copying kpasswd to the local file system and using a checker of his own
> choosing.
>
> I think it would be much more effective if the passwd was verified by
> kasserver before it updated the kas db!
Yeah, I agree with you, at least partly. We had several constraints,
however:
1. backward compatibility had to be maintained.
2. admins could be not expected to _replace_ kpasswd with their own
custom version of kpasswd.
Because of #1, old versions of kpasswd would continue to work, and
clever users could write their own versions of kpasswd using the
existing RPC.
We did consider punting #1, or phasing it out over a couple of years.
Unfortunately, that would require sending the actual password over the
wire. Now, we would encrypt it of course, but the kaserver would
decrypt it and inspect it, which would provide an opportunity for an
unscrupulous admin (or a "cracked" kaserver) to record passwords.
Somebody is probably thinking "but the key is all you need." That's
true for access to *this* cell, but to impersonate someone in another
cell you need their password. People frequently use the same password
in multiple cells -- it was that realization that drove us to use the
cell name in our string-to-key algorithm.
So that sort of complicates things. Now let me rationalize a bit.
Probably the most important factor in maintaining the security of an
AFS cell is the quality of the passwords chosen (especially those of
admins, of course.) Given that, what rational person would choose to
permit their ID to be compromised? So we decided to provide a tool to
assist rational people in choosing good passwords. (I'm going to get
some flames on this, but I am willing to debate further whether users
are truly rational. I will contend that they are almost always as
rational as admins.) The trouble is that "good" can mean a number of
things. The standard rules like "must contain upper and lower-case
letters", "must contain at least one digit and one punctuation mark"
are needlessly narrow. For example, passwords in AFS can be up to
1024 bytes long. A 24-character lower-case alphabetic password can be
just as strong as an 8-character mixed-case password with a single
digit and a punctutation mark.
So from a security perspective, I think the kpwvalid stuff is ok as
is. I do think that it could be easier to configure, but that doesn't
seem to be your issue, Chris.
> 3. The monitors (afsmon, scout, etc)
>
> I wish all of these had script exits when trigger conditions were met.
> (Analogous to the -notify option in #1). My reasoning is the same as it
> is for #1, as well.
agreed.
