| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
|
| |
|
|
| |
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
|
| |
|
|
|
|
| |
Test and confirm that the two implementations agree.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
|
| |
|
|
|
|
|
| |
strings.ReplaceAll() needlessly limits the vintage of Go compiler we
can support. Use strings.Replace(..., -1) instead.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
|
| |
|
|
|
|
|
|
|
|
|
| |
I want a place to capture nuances in these files through experience
and bug reports/patches.
Make use of these to document the Go cap package definitions of each
Value so that the godoc automated documentation at places like go.dev
become more useful for actually using the package.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes Hussam Al-Tayeb bug report:
https://bugzilla.kernel.org/show_bug.cgi?id=208439
The list generation has been intended to be fully self-defined
since 2.23, but I didn't complete the job back then because of
a lack of a way to runtime-determine the capabilities actually
supported by the running kernel. This last bit was fixed with
2.30 and I should have caught the need for this final clean up
then.
The go install was broken in 2.37 as a oversight as I refactored
to support go modules. I did a write up about how this Go
support is expected to work here:
https://sites.google.com/site/fullycapable/building-go-programs-that-manipulate-capabilities
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
I've written up how to build web.go here:
https://sites.google.com/site/fullycapable/building-go-programs-that-manipulate-capabilities
But it struc me that the code itself does not explain about the
CGO_LDFLAGS_ALLOW workaround, so I've relocated the web.go code
and included a README as well as a pointer to the above explanation.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Cleaned up the Go module redirection html file, now installed
at:
https://kernel.org/pub/linux/libs/security/libcap/
Note, I've moved the C source for libpsx.a into the psx/
directory, but the libpsx.a file is still built in the libcap
subdirectory as before. I also symlinked the C include files from
the psx/ directory. This made the source compile in conjuction
with the "psx" Go package automatically. It also substantially
simplified the go/Makefile.
I feel pretty good about this next version from the perspective
of a viable "psx" build. Caveat the need for CGO_LDFLAGS_ALLOW
on the command line pre-go1.15. Hopefully, the psx package comment
is enough for folk to figure that detail out.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After reading more about Go modules, I now see how ownership of the
stable URL path for the packages is required. As such, I'm changing
the official package paths to these:
"kernel.org/pub/linux/libs/security/libcap/cap"
"kernel.org/pub/linux/libs/security/libcap/psx"
I have the right permissions to maintain these directories. I will
place the libcap/{cap,psx}/index.html files at those locations and
then validate that the go getting magic does the right things.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It has been requested that we make the "libcap/cap" package into
a module that plays better with the golang ecosystem. I was holding
off until there was a golang version that contained the
runtime.AllThreadsSyscall() support, but that appears to not have
made it to 1.15, so I'm using a development build tag dependency
in otherwise static sources for the "libcap/cap" package.
My intention is that the canonical import paths for these packages
will be:
"git.kernel.org/libs/libcap/cap"
"git.kernel.org/libs/libcap/psx"
That being said, I may have to move them if I can't get some
proxy to resolve these paths to the right git repo of kernel.org.
The is work in the direction of addressing:
https://bugzilla.kernel.org/show_bug.cgi?id=207567
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The latest iteration of the golang patch [*] for supporting a
syscall API that can normalize privilege over the whole runtime
(aka POSIX semantics) has renamed this API. The API also now
drops this functionality when CGO is enabled, but that doesn't
affect libcap because libcap uses libpsx in this build
configuration.
[*] https://go-review.googlesource.com/c/go/+/210639/
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
|
| |
|
|
| |
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
|
| |
|
|
|
|
|
|
| |
From a Go runtime provide a convenient way to launch a different
process with modified capabilities etc. without disturbing the
security state of the parent.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
|
| |
|
|
|
|
|
| |
Under Linux there are three inheritable vectors worth of capability
vectors. A and B require privilege to set.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
[This will be included in libcap-2.29.]
This change concerns the text formating functions:
C: cap_to_text(), cap_from_text()
Go: cap.FromText() and cap.Set.String()
Prior to this commit, "all" meant every bit of the capability vector
was raised - both named, and unnamed capabilities. Which following some
changes to the kernel (to clip the bounding set to only named values)
broke for libcap. I tried to work around it in 2008, but my workaround
was considered ugly and I now see was only partial...
This partial fix led to what I consider an outstanding kernel bug, and
'all' being unusable for process capabilities. So, this libcap change
is intended to undo my part of the error. While it gives tidier,
self-consistent output, it does introduce a backward incompatibility
in behavior...
After this commit 'all' means all the known/named capabilities only.
That is, as of today, Linux has 38 capabilities defined: 0 (cap_chown)
to 37 (cap_audit_read). So, today, 'all' means all 38 of these raised
and the remaining 26 'unnamed' capabilities lowered.
This has the following effect:
old_libcap_tools:
$ /sbin/getpcaps 1
Capabilities for `1': = cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend,cap_audit_read+ep
$ echo exit > oldall
$ chmod +x oldall
$ sudo /sbin/setcap =ep oldall
$ /sbin/getcap oldall
oldall =ep
new_libcap_tools:
$ ./getpcaps 1
Capabilities for `1': =ep
$ echo exit > newall
$ chmod +x newall
$ sudo ./setcap =ep newall
$ ./getcap newall oldall
newall =ep
oldall =ep 38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63+ep
old_libcap_tools:
$ /sbin/getcap oldall newall
oldall =ep
newall = cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend,cap_audit_read+ep
Cc: "Serge E. Hallyn" <serge@hallyn.com>
Cc: Michael Kerrisk <mtk.manpages@gmail.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: linux-security-module <linux-security-module@vger.kernel.org>
Cc: ksrot@redhat.com
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As well as substantial updates to the man pages, including
an explanation of how capabilities can be robustly used with
pthreads, implement a set of convenience functions in libcap
to make dropping privilege in careful ways straightforward.
These include adding the abstraction of libcap recommended
"modes" and cap_setuid() and cap_setgroups() functions.
The progs/quicktest.sh script and capsh has been extended
to validate each of these new functions.
Add convenience functions to the libcap/cap Go package.
Specifically, added Compare(), Differs(), GetSecbits() &
Secbits.Set(), GetMode() & Mode.Set(), SetUID() and
SetGroups().
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
|
| |
|
|
|
|
|
|
| |
The latter will invoke tests with sudo. Not all builds
can support this, but we do need a convenient way
to test this stuff...
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Also install the Go packages if built.
Remove a default behavior of installing an inheritable bit on setcap.
I'm getting alarmed that some distributions are setting the inheritable
set to full for all users. So, I don't want to provide a vector for
a trivial exploit, and hope they are not reinventing this:
https://sites.google.com/site/fullycapable/Home/thesendmailcapabilitiesissue
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I've moved my go.patch to address:
https://github.com/golang/go/issues/1435
into a development patch against the upstream Go sources:
https://go-review.googlesource.com/c/go/+/210639/
and the review process will likely evolve it somewhat. I plan to
ensure that working libcap/cap Go package is in sync with the
working state of the above development change.
As such, there is no need to keep the patch here any more.
I'll keep the tests for now, as it isn't clear to me how the Go
source tree supports tests that require privilege yet.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
|
| |
|
|
|
|
| |
It looks like a Make difference.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
|
| |
|
|
|
|
|
| |
I've been having some trouble with a different version of the
go tool complaining about relative directories.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
|
| |
|
|
|
|
|
|
|
|
|
| |
By default, we are installing "libcap/cap" and "libcap/psx"
in "/usr/share/gocode/src/". To make this work, we also install
"libpsx.a" with "libcap.*".
[If anyone wants to contribute a go .pc/.pc.in file for the Go
packages, that would be appreciated.]
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
|
| |
|
|
|
|
|
|
| |
Also, need to force CGO_ENABLED=0 to take advantage of pure
Go support for syscall.PosixSyscall when available (ie. for
web.go in this tree).
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Note, this override only supports the system calls that
libcap uses to change kernel state associated with the
current process. This is primarily intended to permit the
user to use libpsx to force all pthreads to mirror capability
and other security relevant state.
Use a weak function definition feature of libpsx share_psx_syscall()
to transparently arrange for libcap to so force itself to use the
psx_syscall() abstraction when linked against -lpsx. This has the
effect of using linker magic to make libcap transparently observe
POSIX semantics for security state setting operations. That is, when
linked as follows:
gcc .... -lcap -lpsx -lpthread -Wl,-wrap,pthread_create
all pthreads maintain a common security state with respect to the
libcap API.
This also adds full capability setting support to the Go package
libcap/cap via a libcap/psx package which uses cgo+libpsx syscalls
that share capabilities over all pthreads including those of the
Go runtime.
Finally, if Go supports syscall.PosixSyscall() etc. then provide
a non-psx mechanism for libcap/cap to "just work" in all Go code.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
|
| |
|
|
| |
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
|
| |
|
|
|
|
|
|
| |
Reject &cap.Set{} definitions harder. Require the use of cap.NewCap().
Also remove dependence on syscall.*Syscall6() for prctl - our use is
fully covered by the syscall.*Syscall() API.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
|
| |
|
|
| |
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This version of the Go package libcap/cap works well
enough to be used by others. Unfortunately, to use it
we need to apply something like the included patch
(contrib/go.patch) to the build sources for the Go
runtime and syscall packages.
I'll be trying to get these accepted by the Go team
in parallel.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The program web.go uses "libcap/cap" to raise and lower capabilities
in order to bind to a privileged port. Writing this code, I now
realize that Go's runtime is not really suited to minimal privilege
guarantees. The code does raise and lower the effective capability
Value needed, but to be fully robust, we're going to have to wait for
the following issue with the Go runtime to find a resolution:
https://github.com/golang/go/issues/1435
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
|
|
|
The API for this "libcap/cap" package is very similar to libcap.
I've included a substantial interoperability test that validate
libcap(c) and libcap/cap(go) have import/export text and binary
format compatibility.
My motivation for implementing a standalone Go package was for a
cross-compilation issue I ran into (Go is much more friendly for
cross-compilation by default, unless you need to use cgo).
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
|
