2792e598c7
currently, setting any sort of resource limit in a pod does nothing. With the newly refactored creation process in c/common, podman ca now set resources at a pod level meaning that resource related flags can now be exposed to podman pod create. cgroupfs and systemd are both supported with varying completion. cgroupfs is a much simpler process and one that is virtually complete for all resource types, the flags now just need to be added. systemd on the other hand has to be handeled via the dbus api meaning that the limits need to be passed as recognized properties to systemd. The properties added so far are the ones that podman pod create supports as well as `cpuset-mems` as this will be the next flag I work on. Signed-off-by: Charlie Doern <cdoern@redhat.com>
2.4 KiB
The libseccomp-golang Security Vulnerability Handling Process
https://github.com/seccomp/libseccomp-golang
This document document attempts to describe the processes through which sensitive security relevant bugs can be responsibly disclosed to the libseccomp-golang project and how the project maintainers should handle these reports. Just like the other libseccomp-golang process documents, this document should be treated as a guiding document and not a hard, unyielding set of regulations; the bug reporters and project maintainers are encouraged to work together to address the issues as best they can, in a manner which works best for all parties involved.
Reporting Problems
Problems with the libseccomp-golang library that are not suitable for immediate public disclosure should be emailed to the current libseccomp-golang maintainers, the list is below. We typically request at most a 90 day time period to address the issue before it is made public, but we will make every effort to address the issue as quickly as possible and shorten the disclosure window.
- Paul Moore, paul@paul-moore.com
- Tom Hromatka, tom.hromatka@oracle.com
- Kir Kolyshkin, kolyshkin@gmail.com
Resolving Sensitive Security Issues
Upon disclosure of a bug, the maintainers should work together to investigate the problem and decide on a solution. In order to prevent an early disclosure of the problem, those working on the solution should do so privately and outside of the traditional libseccomp-golang development practices. One possible solution to this is to leverage the GitHub "Security" functionality to create a private development fork that can be shared among the maintainers, and optionally the reporter. A placeholder GitHub issue may be created, but details should remain extremely limited until such time as the problem has been fixed and responsibly disclosed. If a CVE, or other tag, has been assigned to the problem, the GitHub issue title should include the vulnerability tag once the problem has been disclosed.
Public Disclosure
Whenever possible, responsible reporting and patching practices should be followed, including notification to the linux-distros and oss-security mailing lists.