Skip to content

Add docs about security contact and threat model #20529

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

Closed
JanZerebecki wants to merge 1 commit into from
Closed

Add docs about security contact and threat model #20529

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 14 additions & 0 deletions SECURITY.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,14 @@
# Reporting Security Issues
Copy link
Member

@martinpitt martinpitt Jun 24, 2024

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/.

Copy link
Member

@Venefilyn Venefilyn Jan 27, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO we can create a https://github.com/cockpit-project/.github with a SECURITY.md and then just have a standard security contact (or have it copied) in the README.md of the project.

Checking the GitHub docs it does recommend one of three places

  • SECURITY.md
  • .github/SECURITY.md
  • docs/SECURITY.md

However, I don't think we should be tied to GitHub specific features unless other forges also take this into account. Quick check of Forgejo didn't reveal any specific file recommendations, so I'd stick with just having it in README.md and then putting GitHub specific contact in https://github.com/cockpit-project/.github

Can see an example of .github repo in Packit for example


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).
9 changes: 9 additions & 0 deletions doc/threat-model.md
View file
Open in desktop
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
Copy link
Member

@martinpitt martinpitt Jun 24, 2024

Choose a reason for hiding this comment

The 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
Copy link
Member

@martinpitt martinpitt Jun 24, 2024

Choose a reason for hiding this comment

The 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.
Copy link
Author

@JanZerebecki JanZerebecki May 28, 2024

Choose a reason for hiding this comment

The 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?

Copy link
Member

@martinpitt martinpitt Jun 24, 2024

Choose a reason for hiding this comment

The 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 ssh remotehost. I.e. a malicious remotehost can't influence the source host.

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.