logo_kerberos.gif

Ops feedback notes 2015-03-03

From K5Wiki
Revision as of 15:08, 6 April 2015 by TomYu (talk | contribs) (New page: {{opsnotes|2015}} Recent vulns? How far back? ;Greg: Some go back a long way, but the advisory should be clear about that. Projects/Reporting-friendly KDB dump format Tom has an e...)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search


Recent vulns? How far back?

Greg
Some go back a long way, but the advisory should be clear about that.

Projects/Reporting-friendly KDB dump format

Tom has an example on his keyinfo branch in GitHub. Should we use symbolic vs numeric for thing like enctypes? Seems to be a preference for short symbolic names.

Some use cases include ensuring that policies are adhered to. Some sites have front end services that do enhanced policy enforcement. Direct use of kadmin, etc. can bypass these policies, so having a way to check by parsing a dumpfile would be nice.

Formats? XML? comma-separated? colon-separated?

For bitfields, do we output all settings, or just the ones that are set? Auditors probably want to be able to see every defined flag regardless of whether it is set. Some question of what to do with new flags that get defined. (Some of this only matters for dump/edit/load capability.)

Different flavors of dump? Maybe one that includes the key data? Sometimes auditors want to run password crackers on the keys. Might also be useful to do a dump/edit/load process. (We will probably focus on a reporting format first.)

Some interest in dump formats that make it easier to use traditional Unix tools like grep, awk, etc. Tab-separated might