seccomp / libseccomp-golang Goto Github PK
View Code? Open in Web Editor NEWThe libseccomp golang bindings repository
License: BSD 2-Clause "Simplified" License
The libseccomp golang bindings repository
License: BSD 2-Clause "Simplified" License
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.
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!
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.
As requested by Phil Estes along with a patch:
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!
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)
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.
$ 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
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.
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 ?
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.
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.
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.
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.
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
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.
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.
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.
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
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.
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;
A new release is needed for the 0.9.x release stream to address CVE-2017-18367, see #22 for more information.
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.
it looks nicer when we vendor into docker/docker, no rush just wondering :)
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
Hey maintainers π, may I ask you to cut a new release that we can utilize the new types in the repository?
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:
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
We have parisc[64] support in the main libseccomp repository and it is scheduled for the v2.4 release.
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:
git branch -m master main
git push origin main
git push origin :master
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",
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
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.
This issue is simply a placeholder/tracking issue to cover a review of the entire libseccomp-golang API prior to the v1.0 release.
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!
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?
Next release of libseccomp-golang v0.9.2 should support RISCV64 because libseccomp v2.5.0 has already supported it.
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)
}
Additional documentation to help guide the libseccomp golang bindings, borrow heavily from the main project.
We should add a documented security policy, similar to the main libseccomp security policy.
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.
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
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.
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
There are plenty of articles on this, but see The Register article below for some background on this issue:
With Travis CI becoming potentially unreliable for libseccomp, we should investigate moving out CI testing to GitHub actions:
A declarative, efficient, and flexible JavaScript library for building user interfaces.
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. πππ
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google β€οΈ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.