Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Revocation severity levels and context #48

Open
THS-on opened this issue Jun 8, 2021 · 2 comments
Open

Revocation severity levels and context #48

THS-on opened this issue Jun 8, 2021 · 2 comments
Labels
backlog

Comments

@THS-on
Copy link
Member

THS-on commented Jun 8, 2021 •
edited
Loading

Enhancement Description

  • One-line enhancement description (can be used as a release note): Adding support for severity levels and (user provided) context to revocation events.
  • Keylime Enhancement Proposal: Proposal for revocation severity levels and context #47
  • Primary contact (assignee): @THS-on
  • Enhancement target (which target equals to which milestone):
    • Alpha release target (x.y)
    • Beta release target (x.y)
    • Stable release target (x.y)

Please to keep this description up to date.
@THS-on THS-on mentioned this issue Jul 26, 2021
Merged
THS-on added a commit to THS-on/keylime that referenced this issue Aug 2, 2021
@THS-on
Add infrastructure to tag and collect revocation events in Keylime
962cfeb 
Currently Keylime operates in a binary state when it comes failures that cause
revocations and does not collect information where and why that revocation
happened.

This commit introduces the tagging and collection infrastructure and
configuration for revocation events and adding context to them.

SeverityLabel
    Has a name that can be set in the keylime.conf and a severity that is
    dynamically calculated based on the order in the configuration.

Components
    Is a enumeration that contains the main components of Keylime that can cause
    events. Must be specified when creating a Failure object.

Event
    Holds a revocation event. An event can be identified by their event_id which
    has the format: "component.[sub_component].event"
    The severity is automatically assigned based on the event_id.
    The event contains a context which is string encoded JSON object.
    An event must be marked irrecoverable if other validation steps are skipped
    by early returning.

Failure
    Holds a collection of events and provides add_event(...) for adding new
    events to it and merge(...) to merge it with another Failure object.

    Is False if no events are currently in the Failure object and is otherwise
    True.

Future changes that cause a revocation must extend and return a Failure object
instead of returning a boolean value.

Part of enhancement proposal keylime/enhancements#48

Signed-off-by: Thore Sommer <[email protected]>
@THS-on THS-on mentioned this issue Aug 2, 2021
Merged
THS-on added a commit to THS-on/keylime that referenced this issue Aug 2, 2021
@THS-on
Add infrastructure to tag and collect revocation events in Keylime
59d38f4 
Currently Keylime operates in a binary state when it comes failures that cause
revocations and does not collect information where and why that revocation
happened.

This commit introduces the tagging and collection infrastructure and
configuration for revocation events and adding context to them.

SeverityLabel
    Has a name that can be set in the keylime.conf and a severity that is
    dynamically calculated based on the order in the configuration.

Components
    Is a enumeration that contains the main components of Keylime that can cause
    events. Must be specified when creating a Failure object.

Event
    Holds a revocation event. An event can be identified by their event_id which
    has the format: "component.[sub_component].event"
    The severity is automatically assigned based on the event_id.
    The event contains a context which is string encoded JSON object.
    An event must be marked irrecoverable if other validation steps are skipped
    by early returning.

Failure
    Holds a collection of events and provides add_event(...) for adding new
    events to it and merge(...) to merge it with another Failure object.

    Is False if no events are currently in the Failure object and is otherwise
    True.

Future changes that cause a revocation must extend and return a Failure object
instead of returning a boolean value.

Part of enhancement proposal keylime/enhancements#48

Signed-off-by: Thore Sommer <[email protected]>
THS-on added a commit to THS-on/keylime that referenced this issue Aug 10, 2021
@THS-on
Add infrastructure to tag and collect revocation events in Keylime
7733668 
Currently Keylime operates in a binary state when it comes failures that cause
revocations and does not collect information where and why that revocation
happened.

This commit introduces the tagging and collection infrastructure and
configuration for revocation events and adding context to them.

SeverityLabel
    Has a name that can be set in the keylime.conf and a severity that is
    dynamically calculated based on the order in the configuration.

Components
    Is a enumeration that contains the main components of Keylime that can cause
    events. Must be specified when creating a Failure object.

Event
    Holds a revocation event. An event can be identified by their event_id which
    has the format: "component.[sub_component].event"
    The severity is automatically assigned based on the event_id.
    The event contains a context which is string encoded JSON object.
    An event must be marked irrecoverable if other validation steps are skipped
    by early returning.

Failure
    Holds a collection of events and provides add_event(...) for adding new
    events to it and merge(...) to merge it with another Failure object.

    Is False if no events are currently in the Failure object and is otherwise
    True.

Future changes that cause a revocation must extend and return a Failure object
instead of returning a boolean value.

Part of enhancement proposal keylime/enhancements#48

Signed-off-by: Thore Sommer <[email protected]>
THS-on added a commit to THS-on/keylime that referenced this issue Aug 30, 2021
@THS-on
failure: add infrastructure to tag and collect revocation events in K…
9a475e8 
…eylime

Currently Keylime operates in a binary state when it comes failures that cause
revocations and does not collect information where and why that revocation
happened.

This commit introduces the tagging and collection infrastructure and
configuration for revocation events and adding context to them.

SeverityLabel
    Has a name that can be set in the keylime.conf and a severity that is
    dynamically calculated based on the order in the configuration.

Components
    Is a enumeration that contains the main components of Keylime that can cause
    events. Must be specified when creating a Failure object.

Event
    Holds a revocation event. An event can be identified by their event_id which
    has the format: "component.[sub_component].event"
    The severity is automatically assigned based on the event_id.
    The event contains a context which is string encoded JSON object.
    An event must be marked irrecoverable if other validation steps are skipped
    by early returning.

Failure
    Holds a collection of events and provides add_event(...) for adding new
    events to it and merge(...) to merge it with another Failure object.

    Is False if no events are currently in the Failure object and is otherwise
    True.

Future changes that cause a revocation must extend and return a Failure object
instead of returning a boolean value.

Part of enhancement proposal keylime/enhancements#48

Signed-off-by: Thore Sommer <[email protected]>
THS-on added a commit to THS-on/keylime that referenced this issue Aug 30, 2021
@THS-on
ima: move to new failure architecture
80c6f21 
Part of enhancement proposal keylime/enhancements#48

Signed-off-by: Thore Sommer <[email protected]>
THS-on added a commit to THS-on/keylime that referenced this issue Aug 30, 2021
@THS-on
measured boot: move to new failure architecture
aabe6ba 
Currently only has one event id. If necessary can be extended such that
policies can generate their own event ids.

Part of enhancement proposal keylime/enhancements#48

Signed-off-by: Thore Sommer <[email protected]>
THS-on added a commit to THS-on/keylime that referenced this issue Aug 30, 2021
@THS-on
pcr validation: move to new failure architecture
64d4fed 
Part of enhancement proposal keylime/enhancements#48

Signed-off-by: Thore Sommer <[email protected]>
THS-on added a commit to THS-on/keylime that referenced this issue Aug 30, 2021
@THS-on
verifier: move to new failure architecture
6792388 
We only send notifications if a event with a higher severity level was
generated and save the severity level (as integer) and the first event id
that generated the failure with that level in the database.

The current design assumes that when a device is added no failures should
occur on the first validation to mark the device as in use to recive
revocation notifcations.

If a failure is generated that is irrecoverable we stop polling the agent.

Part of enhancement proposal keylime/enhancements#48

Signed-off-by: Thore Sommer <[email protected]>
THS-on added a commit to THS-on/keylime that referenced this issue Aug 30, 2021
@THS-on
failure: add infrastructure to tag and collect revocation events in K…
86f6412 
…eylime

Currently Keylime operates in a binary state when it comes failures that cause
revocations and does not collect information where and why that revocation
happened.

This commit introduces the tagging and collection infrastructure and
configuration for revocation events and adding context to them.

SeverityLabel
    Has a name that can be set in the keylime.conf and a severity that is
    dynamically calculated based on the order in the configuration.

Components
    Is a enumeration that contains the main components of Keylime that can cause
    events. Must be specified when creating a Failure object.

Event
    Holds a revocation event. An event can be identified by their event_id which
    has the format: "component.[sub_component].event"
    The severity is automatically assigned based on the event_id.
    The event contains a context which is string encoded JSON object.
    An event must be marked irrecoverable if other validation steps are skipped
    by early returning.

Failure
    Holds a collection of events and provides add_event(...) for adding new
    events to it and merge(...) to merge it with another Failure object.

    Is False if no events are currently in the Failure object and is otherwise
    True.

Future changes that cause a revocation must extend and return a Failure object
instead of returning a boolean value.

Part of enhancement proposal keylime/enhancements#48

Signed-off-by: Thore Sommer <[email protected]>
THS-on added a commit to THS-on/keylime that referenced this issue Aug 30, 2021
@THS-on
ima: move to new failure architecture
bb6aadb 
Part of enhancement proposal keylime/enhancements#48

Signed-off-by: Thore Sommer <[email protected]>
THS-on added a commit to THS-on/keylime that referenced this issue Aug 30, 2021
@THS-on
measured boot: move to new failure architecture
175f95b 
Currently only has one event id. If necessary can be extended such that
policies can generate their own event ids.

Part of enhancement proposal keylime/enhancements#48

Signed-off-by: Thore Sommer <[email protected]>
THS-on added a commit to THS-on/keylime that referenced this issue Aug 30, 2021
@THS-on
pcr validation: move to new failure architecture
8d7faee 
Part of enhancement proposal keylime/enhancements#48

Signed-off-by: Thore Sommer <[email protected]>
THS-on added a commit to THS-on/keylime that referenced this issue Aug 30, 2021
@THS-on
verifier: move to new failure architecture
15c83f9 
We only send notifications if a event with a higher severity level was
generated and save the severity level (as integer) and the first event id
that generated the failure with that level in the database.

The current design assumes that when a device is added no failures should
occur on the first validation to mark the device as in use to recive
revocation notifcations.

If a failure is generated that is irrecoverable we stop polling the agent.

Part of enhancement proposal keylime/enhancements#48

Signed-off-by: Thore Sommer <[email protected]>
THS-on added a commit to THS-on/keylime that referenced this issue Sep 8, 2021
@THS-on
failure: add infrastructure to tag and collect revocation events in K…
247186d 
…eylime

Currently Keylime operates in a binary state when it comes failures that cause
revocations and does not collect information where and why that revocation
happened.

This commit introduces the tagging and collection infrastructure and
configuration for revocation events and adding context to them.

SeverityLabel
    Has a name that can be set in the keylime.conf and a severity that is
    dynamically calculated based on the order in the configuration.

Components
    Is a enumeration that contains the main components of Keylime that can cause
    events. Must be specified when creating a Failure object.

Event
    Holds a revocation event. An event can be identified by their event_id which
    has the format: "component.[sub_component].event"
    The severity is automatically assigned based on the event_id.
    The event contains a context which is string encoded JSON object.
    An event must be marked irrecoverable if other validation steps are skipped
    by early returning.

Failure
    Holds a collection of events and provides add_event(...) for adding new
    events to it and merge(...) to merge it with another Failure object.

    Is False if no events are currently in the Failure object and is otherwise
    True.

Future changes that cause a revocation must extend and return a Failure object
instead of returning a boolean value.

Part of enhancement proposal keylime/enhancements#48

Signed-off-by: Thore Sommer <[email protected]>
THS-on added a commit to THS-on/keylime that referenced this issue Sep 8, 2021
@THS-on
ima: move to new failure architecture
023d717 
Part of enhancement proposal keylime/enhancements#48

Signed-off-by: Thore Sommer <[email protected]>
THS-on added a commit to THS-on/keylime that referenced this issue Sep 8, 2021
@THS-on
measured boot: move to new failure architecture
f562803 
Currently only has one event id. If necessary can be extended such that
policies can generate their own event ids.

Part of enhancement proposal keylime/enhancements#48

Signed-off-by: Thore Sommer <[email protected]>
THS-on added a commit to THS-on/keylime that referenced this issue Sep 8, 2021
@THS-on
pcr validation: move to new failure architecture
1d0c657 
Part of enhancement proposal keylime/enhancements#48

Signed-off-by: Thore Sommer <[email protected]>
THS-on added a commit to THS-on/keylime that referenced this issue Sep 8, 2021
@THS-on
verifier: move to new failure architecture
15d3873 
We only send notifications if a event with a higher severity level was
generated and save the severity level (as integer) and the first event id
that generated the failure with that level in the database.

The current design assumes that when a device is added no failures should
occur on the first validation to mark the device as in use to recive
revocation notifcations.

If a failure is generated that is irrecoverable we stop polling the agent.

Part of enhancement proposal keylime/enhancements#48

Signed-off-by: Thore Sommer <[email protected]>
THS-on added a commit to THS-on/keylime that referenced this issue Sep 8, 2021
@THS-on
failure: add infrastructure to tag and collect revocation events in K…
64e0603 
…eylime

Currently Keylime operates in a binary state when it comes failures that cause
revocations and does not collect information where and why that revocation
happened.

This commit introduces the tagging and collection infrastructure and
configuration for revocation events and adding context to them.

SeverityLabel
    Has a name that can be set in the keylime.conf and a severity that is
    dynamically calculated based on the order in the configuration.

Components
    Is a enumeration that contains the main components of Keylime that can cause
    events. Must be specified when creating a Failure object.

Event
    Holds a revocation event. An event can be identified by their event_id which
    has the format: "component.[sub_component].event"
    The severity is automatically assigned based on the event_id.
    The event contains a context which is string encoded JSON object.
    An event must be marked irrecoverable if other validation steps are skipped
    by early returning.

Failure
    Holds a collection of events and provides add_event(...) for adding new
    events to it and merge(...) to merge it with another Failure object.

    Is False if no events are currently in the Failure object and is otherwise
    True.

Future changes that cause a revocation must extend and return a Failure object
instead of returning a boolean value.

Part of enhancement proposal keylime/enhancements#48

Signed-off-by: Thore Sommer <[email protected]>
THS-on added a commit to THS-on/keylime that referenced this issue Sep 8, 2021
@THS-on
ima: move to new failure architecture
aa91d02 
Part of enhancement proposal keylime/enhancements#48

Signed-off-by: Thore Sommer <[email protected]>
THS-on added a commit to THS-on/keylime that referenced this issue Sep 8, 2021
@THS-on
measured boot: move to new failure architecture
447398b 
Currently only has one event id. If necessary can be extended such that
policies can generate their own event ids.

Part of enhancement proposal keylime/enhancements#48

Signed-off-by: Thore Sommer <[email protected]>
THS-on added a commit to THS-on/keylime that referenced this issue Sep 8, 2021
@THS-on
pcr validation: move to new failure architecture
2763429 
Part of enhancement proposal keylime/enhancements#48

Signed-off-by: Thore Sommer <[email protected]>
THS-on added a commit to THS-on/keylime that referenced this issue Sep 8, 2021
@THS-on
verifier: move to new failure architecture
7c83219 
We only send notifications if a event with a higher severity level was
generated and save the severity level (as integer) and the first event id
that generated the failure with that level in the database.

The current design assumes that when a device is added no failures should
occur on the first validation to mark the device as in use to recive
revocation notifcations.

If a failure is generated that is irrecoverable we stop polling the agent.

Part of enhancement proposal keylime/enhancements#48

Signed-off-by: Thore Sommer <[email protected]>
THS-on added a commit to THS-on/keylime that referenced this issue Sep 13, 2021
@THS-on
failure: add infrastructure to tag and collect revocation events in K…
d882dff 
…eylime

Currently Keylime operates in a binary state when it comes failures that cause
revocations and does not collect information where and why that revocation
happened.

This commit introduces the tagging and collection infrastructure and
configuration for revocation events and adding context to them.

SeverityLabel
    Has a name that can be set in the keylime.conf and a severity that is
    dynamically calculated based on the order in the configuration.

Components
    Is a enumeration that contains the main components of Keylime that can cause
    events. Must be specified when creating a Failure object.

Event
    Holds a revocation event. An event can be identified by their event_id which
    has the format: "component.[sub_component].event"
    The severity is automatically assigned based on the event_id.
    The event contains a context which is string encoded JSON object.
    An event must be marked irrecoverable if other validation steps are skipped
    by early returning.

Failure
    Holds a collection of events and provides add_event(...) for adding new
    events to it and merge(...) to merge it with another Failure object.

    Is False if no events are currently in the Failure object and is otherwise
    True.

Future changes that cause a revocation must extend and return a Failure object
instead of returning a boolean value.

Part of enhancement proposal keylime/enhancements#48

Signed-off-by: Thore Sommer <[email protected]>
THS-on added a commit to THS-on/keylime that referenced this issue Sep 13, 2021
@THS-on
ima: move to new failure architecture
b962317 
Part of enhancement proposal keylime/enhancements#48

Signed-off-by: Thore Sommer <[email protected]>
THS-on added a commit to THS-on/keylime that referenced this issue Sep 13, 2021
@THS-on
measured boot: move to new failure architecture
702a83f 
Currently only has one event id. If necessary can be extended such that
policies can generate their own event ids.

Part of enhancement proposal keylime/enhancements#48

Signed-off-by: Thore Sommer <[email protected]>
THS-on added a commit to THS-on/keylime that referenced this issue Sep 13, 2021
@THS-on
pcr validation: move to new failure architecture
f4db5f3 
Part of enhancement proposal keylime/enhancements#48

Signed-off-by: Thore Sommer <[email protected]>
THS-on added a commit to THS-on/keylime that referenced this issue Sep 13, 2021
@THS-on
verifier: move to new failure architecture
f31028c 
We only send notifications if a event with a higher severity level was
generated and save the severity level (as integer) and the first event id
that generated the failure with that level in the database.

The current design assumes that when a device is added no failures should
occur on the first validation to mark the device as in use to recive
revocation notifcations.

If a failure is generated that is irrecoverable we stop polling the agent.

Part of enhancement proposal keylime/enhancements#48

Signed-off-by: Thore Sommer <[email protected]>
THS-on added a commit to THS-on/keylime that referenced this issue Sep 13, 2021
@THS-on
failure: add infrastructure to tag and collect revocation events in K…
4430b76 
…eylime

Currently Keylime operates in a binary state when it comes failures that cause
revocations and does not collect information where and why that revocation
happened.

This commit introduces the tagging and collection infrastructure and
configuration for revocation events and adding context to them.

SeverityLabel
    Has a name that can be set in the keylime.conf and a severity that is
    dynamically calculated based on the order in the configuration.

Components
    Is a enumeration that contains the main components of Keylime that can cause
    events. Must be specified when creating a Failure object.

Event
    Holds a revocation event. An event can be identified by their event_id which
    has the format: "component.[sub_component].event"
    The severity is automatically assigned based on the event_id.
    The event contains a context which is string encoded JSON object.
    An event must be marked irrecoverable if other validation steps are skipped
    by early returning.

Failure
    Holds a collection of events and provides add_event(...) for adding new
    events to it and merge(...) to merge it with another Failure object.

    Is False if no events are currently in the Failure object and is otherwise
    True.

Future changes that cause a revocation must extend and return a Failure object
instead of returning a boolean value.

Part of enhancement proposal keylime/enhancements#48

Signed-off-by: Thore Sommer <[email protected]>
THS-on added a commit to THS-on/keylime that referenced this issue Sep 13, 2021
@THS-on
ima: move to new failure architecture
e2b9d89 
Part of enhancement proposal keylime/enhancements#48

Signed-off-by: Thore Sommer <[email protected]>
THS-on added a commit to THS-on/keylime that referenced this issue Sep 13, 2021
@THS-on
measured boot: move to new failure architecture
44d08b3 
Currently only has one event id. If necessary can be extended such that
policies can generate their own event ids.

Part of enhancement proposal keylime/enhancements#48

Signed-off-by: Thore Sommer <[email protected]>
THS-on added a commit to THS-on/keylime that referenced this issue Sep 13, 2021
@THS-on
pcr validation: move to new failure architecture
dd212a6 
Part of enhancement proposal keylime/enhancements#48

Signed-off-by: Thore Sommer <[email protected]>
THS-on added a commit to THS-on/keylime that referenced this issue Sep 13, 2021
@THS-on
verifier: move to new failure architecture
06645a8 
We only send notifications if a event with a higher severity level was
generated and save the severity level (as integer) and the first event id
that generated the failure with that level in the database.

The current design assumes that when a device is added no failures should
occur on the first validation to mark the device as in use to recive
revocation notifcations.

If a failure is generated that is irrecoverable we stop polling the agent.

Part of enhancement proposal keylime/enhancements#48

Signed-off-by: Thore Sommer <[email protected]>
mpeters pushed a commit to keylime/keylime that referenced this issue Sep 13, 2021
@THS-on @mpeters
failure: add infrastructure to tag and collect revocation events in K…
a976c65 
…eylime

Currently Keylime operates in a binary state when it comes failures that cause
revocations and does not collect information where and why that revocation
happened.

This commit introduces the tagging and collection infrastructure and
configuration for revocation events and adding context to them.

SeverityLabel
    Has a name that can be set in the keylime.conf and a severity that is
    dynamically calculated based on the order in the configuration.

Components
    Is a enumeration that contains the main components of Keylime that can cause
    events. Must be specified when creating a Failure object.

Event
    Holds a revocation event. An event can be identified by their event_id which
    has the format: "component.[sub_component].event"
    The severity is automatically assigned based on the event_id.
    The event contains a context which is string encoded JSON object.
    An event must be marked irrecoverable if other validation steps are skipped
    by early returning.

Failure
    Holds a collection of events and provides add_event(...) for adding new
    events to it and merge(...) to merge it with another Failure object.

    Is False if no events are currently in the Failure object and is otherwise
    True.

Future changes that cause a revocation must extend and return a Failure object
instead of returning a boolean value.

Part of enhancement proposal keylime/enhancements#48

Signed-off-by: Thore Sommer <[email protected]>
mpeters pushed a commit to keylime/keylime that referenced this issue Sep 13, 2021
@THS-on @mpeters
ima: move to new failure architecture
1ce3fe7 
Part of enhancement proposal keylime/enhancements#48

Signed-off-by: Thore Sommer <[email protected]>
mpeters pushed a commit to keylime/keylime that referenced this issue Sep 13, 2021
@THS-on @mpeters
measured boot: move to new failure architecture
3dbdeb8 
Currently only has one event id. If necessary can be extended such that
policies can generate their own event ids.

Part of enhancement proposal keylime/enhancements#48

Signed-off-by: Thore Sommer <[email protected]>
mpeters pushed a commit to keylime/keylime that referenced this issue Sep 13, 2021
@THS-on @mpeters
pcr validation: move to new failure architecture
4240338 
Part of enhancement proposal keylime/enhancements#48

Signed-off-by: Thore Sommer <[email protected]>
mpeters pushed a commit to keylime/keylime that referenced this issue Sep 13, 2021
@THS-on @mpeters
verifier: move to new failure architecture
e6703aa 
We only send notifications if a event with a higher severity level was
generated and save the severity level (as integer) and the first event id
that generated the failure with that level in the database.

The current design assumes that when a device is added no failures should
occur on the first validation to mark the device as in use to recive
revocation notifcations.

If a failure is generated that is irrecoverable we stop polling the agent.

Part of enhancement proposal keylime/enhancements#48

Signed-off-by: Thore Sommer <[email protected]>
@mpeters
Copy link
Member

mpeters commented Feb 3, 2022

@THS-on I believe this enhancement issue can be closed, correct?

@THS-on
Copy link
Member Author

THS-on commented Feb 3, 2022

I like to keep this open till we tested that feature in more production and added better documentation.

@THS-on THS-on added the backlog label Jul 13, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
backlog
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@mpeters @THS-on