seccomp / libseccomp-golang Goto Github PK

The libseccomp golang bindings repository

License: BSD 2-Clause "Simplified" License

Go 99.32% Makefile 0.68%

libseccomp-golang's Introduction

https://github.com/seccomp/libseccomp-golang

The libseccomp library provides an easy to use, platform independent, interface to the Linux Kernel's syscall filtering mechanism. The libseccomp API is designed to abstract away the underlying BPF based syscall filter language and present a more conventional function-call based filtering interface that should be familiar to, and easily adopted by, application developers.

The libseccomp-golang library provides a Go based interface to the libseccomp library.

Online Resources

The library source repository currently lives on GitHub at the following URLs:

Documentation for this package is also available at:

https://pkg.go.dev/github.com/seccomp/libseccomp-golang

Verifying Releases

Starting with libseccomp-golang v0.10.0, the git tag corresponding to each release should be signed by one of the libseccomp-golang maintainers. It is recommended that before use you verify the release tags using the following command:

% git tag -v <tag>

At present, only the following keys, specified via the fingerprints below, are authorized to sign official libseccomp-golang release tags:

Paul Moore <[email protected]>
7100 AADF AE6E 6E94 0D2E  0AD6 55E4 5A5A E8CA 7C8A

Tom Hromatka <[email protected]>
47A6 8FCE 37C7 D702 4FD6  5E11 356C E62C 2B52 4099

Kir Kolyshkin <[email protected]>
C242 8CD7 5720 FACD CF76  B6EA 17DE 5ECB 75A1 100E

More information on GnuPG and git tag verification can be found at their respective websites: https://git-scm.com/docs/git and https://gnupg.org.

Installing the package

% go get github.com/seccomp/libseccomp-golang

Contributing

See CONTRIBUTING.md.

libseccomp-golang's People

Contributors

Stargazers

Watchers

libseccomp-golang's Issues

RFE: add seccomp notifier support

I saw that libseccomp 2.5.0 added 6 new notifier APIs:

int seccomp_notify_alloc(struct seccomp_notif **req, struct seccomp_notif_resp **resp);
void seccomp_notify_free(struct seccomp_notif *req, struct seccomp_notif_resp *resp);
int seccomp_notify_receive(int fd, struct seccomp_notif *req);
int seccomp_notify_respond(int fd, struct seccomp_notif_resp *resp);
int seccomp_notify_id_valid(int fd, uint64_t id);
int seccomp_notify_fd(const scmp_filter_ctx ctx);

Referring to #37, I think it would make sense to add the binding and structures to this project, too. I could take care of the implementation/testing if you want. WDYT?

BUG: Handling of multiple syscall arguments incorrect (CVE-2017-18367)

Issue originally identified at moby/moby#32714

Presently, when adding a rule with multiple syscall arguments, we add each argument separately with a separate call to seccomp_rule_add_array and a single syscall specified. This produces an OR relationship between the arguments - IE, we will match if any of the arguments match.

However, using libseccomp directly, adding multiple rules at the same time with a single API call will result in an AND relationship - the rule will only match if all of the arguments match.

Matching the behavior of the library is important, and at present use cases requiring ANDing syscall rules are not supported.

Q: enable seccomp notify for API level 5, linux kernel 5.6 and below

Hi, seccomp team. First of all, Thanks for maintaining a great library.

As the title says, is it possible to make seccomp notify available for API level 5, linux kernel 5.6 and below?
I think it would be possible by providing an interface to change the TSYNC settings.
fc02980

If you don't mind, I'd like to tryit.

BUG: mismatched types C.uint32_t and C.uint on older gcc versions

root@meihuabo:~/goWorkspace/src/github.com/seccomp/libseccomp-golang# go install 
# github.com/seccomp/libseccomp-golang
./seccomp_internal.go:298: invalid operation: in.toNative() == *_Cvar_C_ARCH_BAD (mismatched types C.uint32_t and C.uint)
./seccomp_internal.go:328: invalid case *_Cvar_C_ARCH_X86 in switch on a (mismatched types C.uint and C.uint32_t)
./seccomp_internal.go:330: invalid case *_Cvar_C_ARCH_X86_64 in switch on a (mismatched types C.uint and C.uint32_t)
./seccomp_internal.go:332: invalid case *_Cvar_C_ARCH_X32 in switch on a (mismatched types C.uint and C.uint32_t)
./seccomp_internal.go:334: invalid case *_Cvar_C_ARCH_ARM in switch on a (mismatched types C.uint and C.uint32_t)
./seccomp_internal.go:336: invalid case *_Cvar_C_ARCH_NATIVE in switch on a (mismatched types C.uint and C.uint32_t)
./seccomp_internal.go:338: invalid case *_Cvar_C_ARCH_AARCH64 in switch on a (mismatched types C.uint and C.uint32_t)
root@AY14052923334089220fZ:/mydata/goWorkspace/gotest/src/github.com/seccomp/libseccomp-golang# nt and C.uint32_t)

server info:

Ubuntu 12.04.5 LTS \n \l

Linux meihuabo 3.8.0-44-generic #66~precise1-Ubuntu SMP Tue Jul 15 04:01:04 

go version go1.4.1    linux/amd64

issue in runc mismatched types C.uint32_t and C.uint

Q: please cut a 0.9.1.1 release with RISC-V support

v0.9.2 milestore is not ready yet, but there is riscv64 support in master, can you please bump v0.9.2 milestone work to v0.9.3 and release v0.9.2 already as is? or like tag and release v0.9.1.1? it would help a lot with riscv64 bootstrapping.

RFE: set the SCMP_FLTATR_CTL_TSYNC by default in the golang bindings

Hi,

Due to the way the go runtime works (right off the bat on starts a handful of threads),
calling SetTsync(true) in Load() might reduce surprises for the package users.

Further, as a golang programmer, you have no control over thread creation / destruction or
scheduling (there are nuances here, but generally) so this doesn't map very well.

I'd go further, and suggest the API for setting/clearing this attribute should be removed
from the package and this just be done implicitly at Load time.

Prompted by opencontainers/runc#1212

Comments ?

BUG: fix problems found via "make lint"

A number of problems were found when running "make lint" (running golint) on HEAD 4387a10:

seccomp.go:353:6: func GetApi should be GetAPI
seccomp.go:363:6: func SetApi should be SetAPI
seccomp.go:616:10: if block ends with a return statement, so drop this else and outdent its block (move short variable declaration to its own line if necessary)
seccomp.go:651:10: if block ends with a return statement, so drop this else and outdent its block (move short variable declaration to its own line if necessary)
seccomp_internal.go:249:6: func getApi should be getAPI
seccomp_internal.go:259:6: func setApi should be setAPI
seccomp_test.go:67:6: func ApiLevelIsSupported should be APILevelIsSupported
seccomp_test.go:90:6: var expectedApi should be expectedAPI
Found 8 lint suggestions; failing.

RFE: add CHANGELOG and SUBMITTING_PATCHES

Additional documentation to help guide the libseccomp golang bindings, borrow heavily from the main project.

RFE: add support for MIPS/PPC/s390 to the golang bindings

As requested by Phil Estes along with a patch:

https://groups.google.com/forum/#!topic/libseccomp/JXRvNsdGGPw

BUG: Replace TravisCI Badge with Github Actions Badge

BUG: Unit test TestRuleAddAndLoad fails on armhf

Debian version 0.0~git20150813.0.1b506fc-2 already applied b03f1ef, so issues on i386 got resolved. Thanks for help!

However, I find that version still fails on armhf:
https://tests.reproducible-builds.org/debian/rbuild/testing/armhf/golang-github-seccomp-libseccomp-golang_0.0~git20150813.0.1b506fc-2.rbuild.log

related log is (hopefully):
=== RUN TestRuleAddAndLoad
--- FAIL: TestRuleAddAndLoad (0.00s)
seccomp_test.go:453: Error loading filter: invalid argument
seccomp_test.go:459: Syscall should have returned error code!
seccomp_test.go:465: Syscall should have returned error code!
FAIL
exit status 1

If you want to compare the build log on i386, it's here:
https://tests.reproducible-builds.org/debian/rbuild/testing/i386/golang-github-seccomp-libseccomp-golang_0.0~git20150813.0.1b506fc-2.rbuild.log

Thank you!

RFE: add support for RISCV64

Next release of libseccomp-golang v0.9.2 should support RISCV64 because libseccomp v2.5.0 has already supported it.

BUG: documented CompareMaskedEqual value order incorrect

The libseccomp-golang documentation says:

    // CompareMaskedEqual returns true if the argument is equal to the given
    // value, when masked (bitwise &) against the second given value
    CompareMaskedEqual ScmpCompareOp = iota

However the libseccomp man page has:

       SCMP_CMP_MASKED_EQ
              Matches when the masked argument value is equal to the masked
              datum value, example:

              SCMP_CMP( arg , SCMP_CMP_MASKED_EQ , mask , datum )

This suggests that the mask is the first value, not the second.

RFE: Add support for SCMP_FLTATR_CTL_SSB

runc needs to use SCMP_FLTATR_CTL_SSB in opencontainers/runc#2430 to make bytecode interpreters including Ruby and Python faster when users can disable mitigation.

ADMIN: change maintainers of the libseccomp-golang project

With @mheon stepping down (see this comment in PR #35) let's shift maintenance of the the libseccomp golang bindings to @drakenclimber and myself. The checklist below is a work in progress (expect it to be edited while this issue remains open) but should be used to guide this work.

Work Items:

RFE: enable Travis CI testing

We should setup some form of integration with Travis CI as soon as possible. Even if we don't have any tests to run we should at least ensure the bindings build, there are no gofmt or golint problems, etc.

RFE: create a new minor release for the 0.9.x release stream

A new release is needed for the 0.9.x release stream to address CVE-2017-18367, see #22 for more information.

BUG: rename the "master" branch to "main" #255

Similar to PR #246 we need to change the name of the "master" branch to "main", or similar. This is quite easy, and via a branch rename, it can be done without losing any of the git history; there is no good reason to not do this.

The steps are simple:

Rename the local git repostory: git branch -m master main
Push the "main" branch to GitHub: git push origin main
Switch the default branch on GitHub to "main" (see Settings -> Branches)
Merge any outstanding PRs against "master" into "main"
Update the badges in README.md to reference the "main" branch
Once all PR's referencing "master" have been merged, delete the "master" branch: git push origin :master

Does Docker(Moby) still utilize libeseccomp-golang?

In the latest version of Docker, I found that the only occurrence of libseccomp-golang is GetNativeArch() https://github.com/moby/moby/blob/cfeba5af9ec522565fb527a78d97081cbb75ce8f/profiles/seccomp/seccomp.go#L66,

I was wondering whether the other APIs like
func (f *ScmpFilter) Load() error
func (f *ScmpFilter) AddRule(call ScmpSyscall, action ScmpAction) error
are still be utilized by Docker?

Basically, I don't find the location in Docker's source code to load the seccomp filter to linux kernel.

Thanks for your help~

Basicsally

Q: Is there any way for the NotifReceive function to end？

When no more information is generated in ScmpFd, the NotifReceive function will block and will not return a value. At this time, the process corresponding to ScmpFd has exited, so there is no need to monitor again. Is there any way to end the NotifReceive function?

func NotifReceive(fd ScmpFd) (*ScmpNotifReq, error) {
	return notifReceive(fd)
}

Q: review libseccomp-golang API for v1.0 release

This issue is simply a placeholder/tracking issue to cover a review of the entire libseccomp-golang API prior to the v1.0 release.

RFE: ensure parity with the current libseccomp release

The libseccomp golang bindings have lagged the main libseccomp release for some time now. Before the next release of the bindings we need to go through and ensure that all of the main libseccomp functionality (e.g. ABI support, new APIs, etc.) that makes sense in golang is supported in the golang bindings.

Q: cut a new release

Hey maintainers 👋, may I ask you to cut a new release that we can utilize the new types in the repository?

BUG: unable to compile on Archlinux

Attempts to compile this library on Archlinux for using snap result in the following error:

# github.com/snapcore/snapd/vendor/github.com/seccomp/libseccomp-golang
../go/src/github.com/snapcore/snapd/vendor/github.com/seccomp/libseccomp-golang/seccomp_internal.go:630:2: duplicate case _Ciconst_C_ACT_KILL_THREAD (value 0) in switch
	previous case at ../go/src/github.com/snapcore/snapd/vendor/github.com/seccomp/libseccomp-golang/seccomp_internal.go:626:2

The library does compile correctly in a clean chroot. The only thing I can really find different in my system versus a clean chroot is that I have CC/CXX set to Clang versus gcc.

BUG: updated README.md to include the first signed release tag version

Currently README.md references v0.9.2 as the first signed release of libseccomp-golang, but we may skip v0.9.2 in favor of 0.10.0. If this happens the README.md file needs to be updated.

Related: #94 (comment)

RFE: add a list of syscalls required for normal go operation

Go runtime requires some syscalls for normal operation (like mmap for memory allocation).

It seems like it's better to provide a list from the library rather than make developers guess.

At least the following are required:

	"mmap",
	"munmap",
	"mprotect",
	"futex",
	"clone",
	"rt_sigreturn",
	"rt_sigprocmask",
	"set_robust_list",
	"sigaltstack",

RFE: add basic golint/gofmt/govet checking

It would be nice to add basic support for the various golang static analysis and formatting tools, similar to what we have in the main libseccomp library, e.g. "make check", "make check-syntax", etc.

RFE: runtime version detection

From #938(opencontainers/runc#938)
There are three variables called verMajor, verMinor, verMicro to identify the version of libseccomp library, but they are fixed after building.If we upgrading the libseccomp library, the binary can not detect the new version.Should we change the detection fix mode to runtime mode such as using pkg --modversion libseccomp

Q: Is there a way to handle SIGSYS/ActTrap in go code?

It seems currently it's not possible to handle the signal by ActTrap seccomp action in go.

As the kernel sets si_code to SYS_SECCOMP (=1), go will dispatch the signal to signal.Notify if it is set to SI_USER (=0). (see runtime/signal_unix.go in sighandler(), SIGSYS is also not flagged as Notify in sigtab_linux_generic.c).

I created a small demo where I also can override siginfo.si_code to 0. In that case Go dispatches the signal but the unfortunate side-effect is that the caller of the syscall is then no longer blocked and returns. I don't know how to prevent that and still it's an ugly hack. https://gist.github.com/yvesf/aa72d055cdaefa25a976ed2a7f86ef3b

What if I want to act on the SIGSYS, for example exit with a certain exit-code or communicate something special to stdout instead of immediately getting the crash traceback?

Thanks for suggestions!

BUG: 'SCMP_MAJOR_VERSION' undeclared

When I use the latest commit, I get these errors while building my application. If I use e3496e3 there's no problem whatsoever.

github.com/seccomp/libseccomp-golang
src/github.com/seccomp/libseccomp-golang/seccomp_internal.go: In function 'get_major_version':
src/github.com/seccomp/libseccomp-golang/seccomp_internal.go:141:29: error: 'SCMP_MAJOR_VERSION' undeclared (first use in this function)
        return (unsigned int)SCMP_MAJOR_VERSION;
                             ^
src/github.com/seccomp/libseccomp-golang/seccomp_internal.go:141:29: note: each undeclared identifier is reported only once for each function it appears in
src/github.com/seccomp/libseccomp-golang/seccomp_internal.go: In function 'get_minor_version':
src/github.com/seccomp/libseccomp-golang/seccomp_internal.go:146:29: error: 'SCMP_MINOR_VERSION' undeclared (first use in this function)
        return (unsigned int)SCMP_MINOR_VERSION;
                             ^
src/github.com/seccomp/libseccomp-golang/seccomp_internal.go: In function 'get_micro_version':
src/github.com/seccomp/libseccomp-golang/seccomp_internal.go:151:29: error: 'SCMP_MICRO_VERSION' undeclared (first use in this function)
        return (unsigned int)SCMP_MICRO_VERSION;
                             ^
Makefile:25: recipe for target 'binary' failed
make: *** [binary] Error 2

Q: Ubuntu 20.04 with installed libseccomp-dev libraries

While trying to install singularity I get this error:

go get github.com/seccomp/libseccomp-golang
# github.com/seccomp/libseccomp-golang
../../go/work/pkg/mod/github.com/seccomp/[email protected]/seccomp_internal.go:24:2: error: #error Minimum supported version of Libseccomp is v2.2.0
   24 | #error Minimum supported version of Libseccomp is v2.2.0
      |  ^~~~~

Any way to make it work? I am so puzzled!

BUG: version checking does not work for executable linked against the shared library

For go binaries that uses shared library, e.g. docker-runc. The version checking really doesn't work. From the look of things, the version is determined at compile time via the header file seccomp.h. So, we have a situation where a published Docker 1.13 RPM probably is built against a version of libseccomp that's older than 2.2.1. The result is a run-time error:

Error response from daemon: oci runtime error: container_linux.go:247: starting container process caused "conditional filtering requires libseccomp version >= 2.2.1

So the user upgraded libseccomp to 2.3 and the error remains. That's because the version check is done against the header values captured at build time. It'd seem that libseccomp-golang works correctly only if libseccomp is statically linked into the binary.

BUG: Unit test fails on x86 platform

Debian version has an issue that unit test fails on x86:

seccomp_test.go:455: Syscall should have returned error code!

checked the code:
err = syscall.Setreuid(uid, euid)
and err seems to be nil, not the expected syscall.Errno(2)
On x64 (amd64) platoform, this cannot be reproduced.

See Debian BTS: https://bugs.debian.org/860618

Q: how to use string condition in AddRuleConditional()

Hello,
I was trying to add a string condition in AddRuleConditional(). ( allow a system call if path parameter is matched.)
However I found it is tricky.
I ever use C code in Golang to cover string into uint64 but it does not work.
I wonder what is the correct way to use string condition ?
Thank you.

RFE: add release process document

We should create a document that outlines the release process. I have found the libseccomp one to be useful.

Also, if we end up merging the test matrix from Pull Request #70, we need to add a step to the release document to update the test matrix in .github/workflows/test.yml

BUG: "AUDIT_ARCH_MIPSEL64" undeclared here (not in a function)

os:linux arch:mips golang :1.7.5
1.yum install libseccomp-devel-2.3.1-3
2.gi clong github.com/seccomp/libseccomp-golang
3.cd github.com/seccomp/libseccomp-golang && go build -v
error
seccomp_internal.go "AUDIT_ARCH_MIPSEL64" undeclared here (not in a function)
const uint32_t C_ARCH_MIPSEL64 = SCMP_ARCH_MIPSEL64;

BUG: look into replacing Travis CI with GitHub actions

There are plenty of articles on this, but see The Register article below for some background on this issue:

https://www.theregister.com/2020/11/02/travis_ci_pricng

With Travis CI becoming potentially unreliable for libseccomp, we should investigate moving out CI testing to GitHub actions:

https://docs.github.com/en/free-pro-team@latest/actions

RFE: drop libseccomp < 2.5.0 support

Currently, this library has a number of quirks and workarounds to work with older libseccomp. Some of these were removed by 449387b.

Requiring libseccomp >= 2.5.0 should simplify some code.

Related: #99

RFE: evaluate README.md

Compare the golang binding's README.md with the main libseccomp README.md to see if any additional edits should be made to the golang's README.md. Whenever possible we should try to remove redundancy between the two, using the main libseccomp README.md as the main reference.

BUG: test failure on ppc64le

$ go test -v . -run TestRuleAddAndLoad
=== RUN   TestRuleAddAndLoad
    seccomp_test.go:588: Syscall should have returned error code!
--- FAIL: TestRuleAddAndLoad (0.00s)

libseccomp-golang/seccomp_test.go

Lines 586 to 588 in 847368b

 pid := syscall.Getpid() 

 if pid != -1 { 

 t.Errorf("Syscall should have returned error code!")

The pid on ppc64le is 1, don't know why it's not minus..

libseccomp is 2.5.0, and libseccomp-golang is head version.

BUG: missing security policy

We should add a documented security policy, similar to the main libseccomp security policy.

RFE: add support for parisc/parisc64

We have parisc[64] support in the main libseccomp repository and it is scheduled for the v2.4 release.

ADMIN: add Kir Kolyshkin as a maintainer

We (@pcmoore and @drakenclimber) have asked @kolyshkin if he would like to join the libseccomp-goland project as a co-maintainer and he graciously agreed (thanks Kir!). This issue is intended to track all of the different things we need to do to ensure Kir is setup properly as a maintainer for the libseccomp-golang bindings.

NOTE: the list items below are subject to change based on the discussion in this issue.

Verify that @kolyshkin has 2FA enabled for his GH account
@kolyshkin should setup a PGP/GPG key if he hasn't already for tag/release signing (RELEASE_PROCESS.md is still a TODO)
Update issue #36 with @kolyshkin's account
Check and update README.md, CONTRIBUTING.md, SECURITY.md, and MAINTAINER_PROCESS.md (pending PR) if needed with @kolyshkin's info
Grant @kolyshkin write access to seccomp/libseccomp-golang

Check negative value in GetSyscallFromName

GetSyscallFromName in seccomp.go may returns negative syscall nr without error. It is not reasonable since syscall can not be negative.

Test case:

[[Code]]
	callNum, err := libseccomp.GetSyscallFromName(call.Name)
	if err != nil {
		logrus.Debugf("unknown seccomp syscall %q ignored", call.Name)
		return nil
	}
	if callNum < 0 {
		fmt.Println("In Seccomp, invalid call", call, callNum, uint32(callNum))
	}

[[Output]]
In Seccomp, invalid call &{timer_settime64 4 <nil> []} -10237 4294957059

Fix:

From ca9418a3e0b73a4f317225ad90c47f095ad6feb6 Mon Sep 17 00:00:00 2001
From: Joy Allen <[email protected]>
Date: Tue, 5 Dec 2023 15:57:01 +0800
Subject: [PATCH] Consider negative syscall nr as NotExist error

C libseccomp may return negative pseudo syscall nr. In this case,
the syscall does not exist.

Signed-off-by: Joy Allen <[email protected]>
---
 seccomp.go | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/seccomp.go b/seccomp.go
index b707c43..54b6aac 100644
--- a/seccomp.go
+++ b/seccomp.go
@@ -495,7 +495,9 @@ func GetSyscallFromName(name string) (ScmpSyscall, error) {
        defer C.free(unsafe.Pointer(cString))
 
        result := C.seccomp_syscall_resolve_name(cString)
-       if result == scmpError {
+       // C libseccomp may return negative pseudo syscall nr on NotExist.
+       // Just checking scmpError is not sufficient here
+       if result < 0 {
                return 0, ErrSyscallDoesNotExist
        }
 
-- 
2.25.1

Q: release tagging

it looks nicer when we vendor into docker/docker, no rush just wondering :)

RFE: add "make lint" to the Travis CI tests

Once we have "make lint" running clean, we should add it to the Travis CI tests. See issue #43 for the "make lint" bug tracker.

	pid := syscall.Getpid()
	if pid != -1 {
	t.Errorf("Syscall should have returned error code!")

seccomp / libseccomp-golang Goto Github PK

libseccomp-golang's Introduction

Online Resources

Verifying Releases

Installing the package

Contributing

libseccomp-golang's People

Contributors

Stargazers

Watchers

Forkers

libseccomp-golang's Issues

Recommend Projects

Recommend Topics

Recommend Org

Jobs