Proposed modifications to replay cache to prevent false positives
Nicolas.Williams at sun.com
Tue May 20 16:16:24 EDT 2008
On Sat, May 10, 2008 at 01:59:23AM -0400, Jeffrey Altman wrote:
> Please review
B-trees won't help that much, and may possibly hurt. Unless...
Will F. greatly improved the performance of the replay cache on Solaris.
The improvement was phenomenal, but fsync() is still the gating factor,
so you get even more perf by putting the rcache in a tmpfs filesystem.
Putting the rcache on tmpfs is technically a problem: any vulnerability
that can allow an attacker to panic your system will allow the attacker
to replay AP-REQs. One solution to that is to not use protocols that
are susceptible to replay attacks (e.g., use SSHv2 instead or r-cmds).
Another is to reduce the skew time on the server to something related to
its time to boot.
I propose that in addition to whatever you do for rcache perf, we do the
- provide an option to set the server-side skew to some number of
seconds, which in general should be estimated time to boot * 2
- provide an option to put the rcache on tmpfs or tmpfs-like
With such an option then a B-tree may be useful.
An rcache implementation as a daemon reached via IPC would be even
More information about the krbdev