-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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.
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
Add docs about security contact and threat model #20529
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,14 @@ | ||
# Reporting Security Issues | ||
|
||
Please see https://access.redhat.com/security/team/contact/ for how to report | ||
an issue. Red Hat Product Security will also take reports for the version of | ||
cockpit in Git, even if that is not a Red Hat Product. | ||
|
||
We take security very seriously, and we aim to take immediate action to address | ||
serious security-related problems that involve cockpit or its infrastructure. | ||
|
||
Further details for the vulnerability process are linked from that page, like | ||
the preference for embargo disclosure timelines of less than 45 days. | ||
|
||
See also the documentation of [the threat model of | ||
cockpit](docs/threat-model.md). |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,9 @@ | ||
Until there is a more concise explanation here about the threat model (what it | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Does this really have to be a separate file? Both SECURITY.md and threat-model.md are tiny, this feels like over-splitting. |
||
defends against) and assurance case (why it is secure), one should be able to | ||
get the necessary informaion from this blog post: | ||
https://cockpit-project.org/blog/is-cockpit-secure.html | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This paragraph is a placeholder, and the blog post is rather dated -- the screenshots don't match current versions any more, and the video is gone. The text is still current, though. Perhaps we should copy the text here then? But that's still not the format of a threat model, "just" a description. |
||
|
||
The post is not exactly clear on this, but there could be a security boundary | ||
between cockpit-ws running on one host and another host where cockpit-bridge is | ||
spawned via ssh, where if the second host was infected with malware it should | ||
be prevented from harming the first. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not satisfied with this last sentence, because it doesn't give a decision. But I'm not in a situation to suggest one way or another. Nor have I reviewed the security. Any suggestion if this should say it currently is or is not treated as a security boundary? @mmartinv I think we talked about this? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. With directly logging into a remote host from the login page, there is a strong security boundary, exactly the same as with However, this completely breaks down when using the "Add new host" functionality. This is somewhere between "extremely hard" and "impossible" to fix, so we are now considering to entirely remove that functionality. See https://issues.redhat.com/browse/COCKPIT-870 for details. Until we figure out how to do that without breaking existing customers, the text here should point out this distinction. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd prefer this to go into README.md, so that it gets rendered in the default github project view. It also creates clutter in the project root dir. It does seem fairly common, though -- which tools look at this? If this is about .well-known/security.txt, that could just point to an anchor in README or a file in doc/.