Merge 88895ca into fb43972

Makefile.am

@@ -24,7 +24,7 @@ pkgconf_DATA = libseccomp.pc
 
 EXTRA_DIST = \
 	CHANGELOG CREDITS LICENSE \
-	README.md CONTRIBUTING.md RELEASE_PROCESS.md
+	README.md CONTRIBUTING.md SECURITY.md
 
 # support silent builds
 AM_MAKEFLAGS_0 = --quiet --no-print-directory

README.md

@@ -110,4 +110,4 @@ these tools are installed by default.
 
 Problems with the libseccomp library can be reported using the GitHub issue
 tracking system or the mailing list.  Those who wish to privately report
-potential vulnerabilities can send mail to paul@paul-moore.com.
+potential vulnerabilities should follow the directions in SECURITY.md.

SECURITY.md

@@ -0,0 +1,45 @@
+The libseccomp Security Vulnerability Handling Process
+===============================================================================
+https://github.com/seccomp/libseccomp
+
+This document document attempts to describe the processes through which
+sensitive security relevant bugs can be responsibly disclosed to the libseccomp
+project and how the project maintainers should handle these reports.  Just like
+the other libseccomp 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 library that are not suitable for immediate public
+disclosure should be emailed to the current libseccomp 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
+
+### 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 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.
+
+* https://oss-security.openwall.org/wiki/mailing-lists/distros

configure.ac

@@ -109,8 +109,8 @@ AC_ARG_ENABLE([python],
 	[build the python bindings, requires cython])])
 AS_IF([test "$enable_python" = yes], [
 	# cython version check
-	AS_IF([test "$CYTHON_VER_MAJ" -eq 0 -a "$CYTHON_VER_MIN" -lt 16], [
-		AC_MSG_ERROR([python bindings require cython 0.16 or higher])
+	AS_IF([test "$CYTHON_VER_MAJ" -eq 0 -a "$CYTHON_VER_MIN" -lt 29], [
+		AC_MSG_ERROR([python bindings require cython 0.29 or higher])
 	])
 	AM_PATH_PYTHON
 ])

doc/admin/MAINTAINER_PROCESS.md

@@ -0,0 +1,95 @@
+The libseccomp Maintainer Process
+===============================================================================
+https://github.com/seccomp/libseccomp
+
+This document attempts to describe the processes that should be followed by the
+various libseccomp maintainers.  It is not intended as a hard requirement, but
+rather as a guiding document intended to make it easier for multiple
+co-maintainers to manage the libseccomp project.
+
+We recognize this document, like all other parts of the libseccomp project, is
+not perfect.  If changes need to be made, they should be made following the
+guidelines described here.
+
+### Reviewing and Merging Patches
+
+In a perfect world each patch would be independently reviewed and ACK'd by each
+maintainer, but we recognize that is not likely to be practical for each patch.
+Under normal circumstances, each patch should be ACK'd by a simple majority of
+maintainers (in the case of an even number of maintainers, N/2+1) before being
+merged into the repository.  Maintainers should ACK patches using a format
+similar to the Linux Kernel, for example:
+
+```
+Acked-by: John Smith <john.smith@email.org>
+```
+
+The maintainer which merged the patch into the repository should add their
+sign-off after ensuring that it is correct to do so (see the documentation on
+submitting patches); if it is not correct for the maintainer to add their
+sign-off, it is likely the patch should not be merged.  The maintainer should
+add their sign-off using the standard format at the end of the patch's
+metadata, for example:
+
+```
+Signed-off-by: Jane Smith <jane.smith@email.org>
+```
+
+The maintainers are encouraged to communicate with each other for many reasons,
+one of which is to let the others when one is going to be unreachable for an
+extended period of time.  If a patch is being held due to a lack of ACKs and
+the other maintainers are not responding after a reasonable period of time (for
+example, a delay of over two weeks), as long as there are no outstanding NACKs
+the patch can be merged without a simple majority.
+
+### Managing Sensitive Vulnerability Reports
+
+The libseccomp vulnerability reporting process is documented in the SECURITY.md
+document.
+
+The maintainers should work together with the reporter to asses the validity
+and seriousness of the reported vulnerability.  Whenever possible, responsible
+reporting and patching practices should be followed, including notification to
+the _linux-distros_ and _oss-security_ mailing lists.
+
+* https://oss-security.openwall.org/wiki/mailing-lists/distros
+
+### Managing the GitHub Issue Tracker
+
+We use the GitHub issue tracker to track bugs, feature requests, and sometimes
+unanswered questions.  The conventions here are intended to help distinguish
+between the different uses, and prioritize within those categories.
+
+Feature requests MUST have a "RFE:" prefix added to the issue name and use the
+"enhancement" label.  Bug reports MUST a "BUG:" prefix added to the issue name
+and use the "bug" label.
+
+Issues SHOULD be prioritized using the "priority/high", "priority/medium", and
+"priority/low" labels.  The meaning should hopefully be obvious.
+
+Issues CAN be additionally labeled with the "pending/info", "pending/review",
+and "pending/revision" labels to indicate that additional information is
+needed, the issue/patch is pending review, and/or the patch requires changes.
+
+### Managing the GitHub Release Milestones
+
+There should be at least two GitHub milestones at any point in time: one for
+the next major/minor release (for example, v2.5), and one for the next patch
+release (for example, v2.4.2).  As issues are entered into the system, they can
+be added to the milestones at the discretion of the maintainers.
+
+### Managing the Public Mailing List
+
+The mailing list is currently hosted on Google Groups, and while it is possible
+to participate in discussions without a Google account, a Google account is
+required to moderate/administer the group.  Those maintainers who do have a
+Google account and wish to be added to the moderators list should be added, but
+there is no requirement to do so.
+
+Despite the term "moderator" the list is currently unmoderated and should
+remain the way.
+
+### New Project Releases
+
+The libseccomp release process is documented in the RELEASE_PROCESS.md
+document.

RELEASE_PROCESS.md → doc/admin/RELEASE_PROCESS.md

@@ -65,7 +65,7 @@ release.
 #### 12. Tag the release in the repository with a signed tag
 
 	# git tag -s -m "version X.Y.Z" vX.Y.Z
-	# git push --tags
+	# git push <repo> vX.Y.Z
 
 #### 13. Build final release tarball
 
@@ -95,3 +95,11 @@ release.
   * libseccomp-X.Y.Z.tar.gz.asc
   * libseccomp-X.Y.Z.tar.gz.SHA256SUM
   * libseccomp-X.Y.Z.tar.gz.SHA256SUM.asc
+
+#### 18. Update the GitHub release notes for older releases which are now unsupported
+
+The following Markdown text is suggested at the top of the release note, see old GitHub releases for examples.
+
+```
+***This release is no longer supported upsteam, please use a more recent release***
+```

src/arch-aarch64-syscalls.c

@@ -171,6 +171,9 @@ const struct arch_syscall_def aarch64_syscall_table[] = { \
 	{ "io_pgetevents", 292 },
 	{ "io_setup", 0 },
 	{ "io_submit", 2 },
+	{ "io_uring_setup", 425 },
+	{ "io_uring_enter", 426 },
+	{ "io_uring_register", 427 },
 	{ "ioctl", 29 },
 	{ "ioperm", __PNR_ioperm },
 	{ "iopl", __PNR_iopl },

src/arch-arm-syscalls.c

@@ -183,6 +183,9 @@ const struct arch_syscall_def arm_syscall_table[] = { \
 	{ "io_pgetevents", (__SCMP_NR_BASE + 399) },
 	{ "io_setup", (__SCMP_NR_BASE + 243) },
 	{ "io_submit", (__SCMP_NR_BASE + 246) },
+	{ "io_uring_setup", (__SCMP_NR_BASE + 425) },
+	{ "io_uring_enter", (__SCMP_NR_BASE + 426) },
+	{ "io_uring_register", (__SCMP_NR_BASE + 427) },
 	{ "ioctl", (__SCMP_NR_BASE + 54) },
 	{ "ioperm", __PNR_ioperm },
 	{ "iopl", __PNR_iopl },

src/arch-mips-syscalls.c

@@ -175,6 +175,9 @@ const struct arch_syscall_def mips_syscall_table[] = { \
 	{ "io_pgetevents", (__SCMP_NR_BASE + 368) },
 	{ "io_setup", (__SCMP_NR_BASE + 241) },
 	{ "io_submit", (__SCMP_NR_BASE + 244) },
+	{ "io_uring_setup", (__SCMP_NR_BASE + 425) },
+	{ "io_uring_enter", (__SCMP_NR_BASE + 426) },
+	{ "io_uring_register", (__SCMP_NR_BASE + 427) },
 	{ "ioctl", (__SCMP_NR_BASE + 54) },
 	{ "ioperm", (__SCMP_NR_BASE + 101) },
 	{ "iopl", (__SCMP_NR_BASE + 110) },

src/arch-mips64-syscalls.c

@@ -175,6 +175,9 @@ const struct arch_syscall_def mips64_syscall_table[] = { \
 	{ "io_pgetevents", (__SCMP_NR_BASE + 328) },
 	{ "io_setup", (__SCMP_NR_BASE + 200) },
 	{ "io_submit", (__SCMP_NR_BASE + 203) },
+	{ "io_uring_setup", (__SCMP_NR_BASE + 425) },
+	{ "io_uring_enter", (__SCMP_NR_BASE + 426) },
+	{ "io_uring_register", (__SCMP_NR_BASE + 427) },
 	{ "ioctl", (__SCMP_NR_BASE + 15) },
 	{ "ioperm", __PNR_ioperm },
 	{ "iopl", __PNR_iopl },

src/arch-mips64n32-syscalls.c

@@ -175,6 +175,9 @@ const struct arch_syscall_def mips64n32_syscall_table[] = { \
 	{ "io_pgetevents", (__SCMP_NR_BASE + 332) },
 	{ "io_setup", (__SCMP_NR_BASE + 200) },
 	{ "io_submit", (__SCMP_NR_BASE + 203) },
+	{ "io_uring_setup", (__SCMP_NR_BASE + 425) },
+	{ "io_uring_enter", (__SCMP_NR_BASE + 426) },
+	{ "io_uring_register", (__SCMP_NR_BASE + 427) },
 	{ "ioctl", (__SCMP_NR_BASE + 15) },
 	{ "ioperm", __PNR_ioperm },
 	{ "iopl", __PNR_iopl },

src/arch-parisc-syscalls.c

@@ -155,6 +155,9 @@ const struct arch_syscall_def parisc_syscall_table[] = { \
 	{ "io_pgetevents", __PNR_io_pgetevents },
 	{ "io_setup",	215 },
 	{ "io_submit",	218 },
+	{ "io_uring_setup", 425 },
+	{ "io_uring_enter", 426 },
+	{ "io_uring_register", 427 },
 	{ "ioctl",	54 },
 	{ "ioperm",	__PNR_ioperm },
 	{ "iopl",	__PNR_iopl },

src/arch-ppc-syscalls.c

@@ -172,6 +172,9 @@ const struct arch_syscall_def ppc_syscall_table[] = { \
 	{ "io_pgetevents", 388 },
 	{ "io_setup", 227 },
 	{ "io_submit", 230 },
+	{ "io_uring_setup", 425 },
+	{ "io_uring_enter", 426 },
+	{ "io_uring_register", 427 },
 	{ "ioctl", 54 },
 	{ "ioperm", 101 },
 	{ "iopl", 110 },

src/arch-ppc64-syscalls.c

@@ -172,6 +172,9 @@ const struct arch_syscall_def ppc64_syscall_table[] = { \
 	{ "io_pgetevents", 388 },
 	{ "io_setup", 227 },
 	{ "io_submit", 230 },
+	{ "io_uring_setup", 425 },
+	{ "io_uring_enter", 426 },
+	{ "io_uring_register", 427 },
 	{ "ioctl", 54 },
 	{ "ioperm", 101 },
 	{ "iopl", 110 },

src/arch-s390-syscalls.c

@@ -155,6 +155,9 @@ const struct arch_syscall_def s390_syscall_table[] = { \
 	{ "io_pgetevents", 382 },
 	{ "io_setup", 243 },
 	{ "io_submit", 246 },
+	{ "io_uring_setup", 425 },
+	{ "io_uring_enter", 426 },
+	{ "io_uring_register", 427 },
 	{ "ioctl", 54 },
 	{ "ioperm", 101 },
 	{ "iopl", __PNR_iopl },

src/arch-s390x-syscalls.c

@@ -155,6 +155,9 @@ const struct arch_syscall_def s390x_syscall_table[] = { \
 	{ "io_pgetevents", 382 },
 	{ "io_setup", 243 },
 	{ "io_submit", 246 },
+	{ "io_uring_setup", 425 },
+	{ "io_uring_enter", 426 },
+	{ "io_uring_register", 427 },
 	{ "ioctl", 54 },
 	{ "ioperm", __PNR_ioperm},
 	{ "iopl", __PNR_iopl },

src/arch-x32-syscalls.c

@@ -171,6 +171,9 @@ const struct arch_syscall_def x32_syscall_table[] = { \
 	{ "io_pgetevents", (X32_SYSCALL_BIT + 333) },
 	{ "io_setup", (X32_SYSCALL_BIT + 543) },
 	{ "io_submit", (X32_SYSCALL_BIT + 544) },
+	{ "io_uring_setup", (X32_SYSCALL_BIT + 425) },
+	{ "io_uring_enter", (X32_SYSCALL_BIT + 426) },
+	{ "io_uring_register", (X32_SYSCALL_BIT + 427) },
 	{ "ioctl", (X32_SYSCALL_BIT + 514) },
 	{ "ioperm", (X32_SYSCALL_BIT + 173) },
 	{ "iopl", (X32_SYSCALL_BIT + 172) },

src/arch-x86-syscalls.c

@@ -171,6 +171,9 @@ const struct arch_syscall_def x86_syscall_table[] = { \
 	{ "io_pgetevents", 385 },
 	{ "io_setup", 245 },
 	{ "io_submit", 248 },
+	{ "io_uring_setup", 425 },
+	{ "io_uring_enter", 426 },
+	{ "io_uring_register", 427 },
 	{ "ioctl", 54 },
 	{ "ioperm", 101 },
 	{ "iopl", 110 },

src/arch-x86_64-syscalls.c

@@ -171,6 +171,9 @@ const struct arch_syscall_def x86_64_syscall_table[] = { \
 	{ "io_pgetevents", 333 },
 	{ "io_setup", 206 },
 	{ "io_submit", 209 },
+	{ "io_uring_setup", 425 },
+	{ "io_uring_enter", 426 },
+	{ "io_uring_register", 427 },
 	{ "ioctl", 16 },
 	{ "ioperm", 173 },
 	{ "iopl", 172 },

src/db.c

@@ -1063,6 +1063,7 @@ int db_col_reset(struct db_filter_col *col, uint32_t def_action)
 	col->attr.nnp_enable = 1;
 	col->attr.tsync_enable = 0;
 	col->attr.api_tskip = 0;
+	col->attr.log_enable = 0;
 
 	/* set the state */
 	col->state = _DB_STA_VALID;

src/python/Makefile.am

@@ -40,12 +40,12 @@ build: ../libseccomp.la libseccomp.pxd seccomp.pyx setup.py
 	${PY_BUILD} && touch build
 
 install-exec-local: build
-	${PY_INSTALL} --install-lib=${DESTDIR}/${pkgpythondir} \
-		--record=${DESTDIR}/${pkgpythondir}/install_files.txt
+	${PY_INSTALL} --install-lib=${DESTDIR}/${pyexecdir} \
+		--record=${DESTDIR}/${pyexecdir}/install_files.txt
 
 uninstall-local:
-	cat ${DESTDIR}/${pkgpythondir}/install_files.txt | xargs ${RM} -f
-	${RM} -f ${DESTDIR}/${pkgpythondir}/install_files.txt
+	cat ${DESTDIR}/${pyexecdir}/install_files.txt | xargs ${RM} -f
+	${RM} -f ${DESTDIR}/${pyexecdir}/install_files.txt
 
 clean-local:
 	[ ${srcdir} == ${builddir} ] || ${RM} -f ${builddir}/seccomp.pyx

src/python/seccomp.pyx

@@ -19,6 +19,8 @@
 # along with this library; if not, see <http://www.gnu.org/licenses>.
 #
 
+# cython: language_level = 3str
+
 """ Python bindings for the libseccomp library
 
 The libseccomp library provides and easy to use, platform independent,