This change introduces an LRU cache (ExecveHashCache) and multi-algorithm
calculation engine (file_hash.go) to store and resolve SHA-256 and SHA-1
digests of executables during execve syscalls.
PiperOrigin-RevId: 952257971
This change adds the execfn field to the ExecveInfo seccheck point.
This field preserves the original, unresolved pathname passed to
execve(2) (used for AT_EXECFN), distinguishing it from BinaryPath,
which contains the fully resolved filesystem path after symlink and
interpreter resolution.
Tests have been updated to verify the distinction between
BinaryPath, Execfn, and Argv[0].
PiperOrigin-RevId: 952211288
This change introduces a new field `binary_overlayfs_lower` in the
`ExecveBinaryInfo` seccheck point. This field is set to true if the executed
binary is found on one of the lower layers of an overlay filesystem. A helper
function `overlay.IsOnLower` is added to determine this. The existing
`binary_overlayfs_upper` field is also clarified to represent any file on
the upper layer.
PiperOrigin-RevId: 949711533
This change introduces a new seccheck field, FieldSentryExecveFdInfo, for the
Execve trace point. When enabled, this field collects information about file
descriptors 0, 1, and 2 (stdin, stdout, stderr) and populates the new stdin,
stdout, and stderr fields in the ExecveInfo proto. The collected FdInfo
includes the file path, mode, inode, whether it's on an overlayfs upper
layer, and socket details (local/remote addresses) if the FD is a socket.
PiperOrigin-RevId: 948482163
This change includes the creation time (ctime) of the executable binary in the
seccheck ExecveInfo and MmapInfo.
The Timespec proto message is moved to common.proto for reuse.
PiperOrigin-RevId: 948385290
This change introduces a new field `binary_overlayfs_upper` to the
`ExecveBinaryInfo` seccheck point. This field is set to true if the executable
being run is located on the upper layer of an overlay filesystem. A new helper
function `overlay.IsCopiedUp` is added to check this condition.
PiperOrigin-RevId: 944568906
This patch introduces pidfd support roughly up to Linux 6.8. Linux selftests
at this version pass, and are now run as an //image_test target. Some features,
like PIDFD_THREAD, that occur later than 6.8 in Linux, are included.
It includes:
- These new syscalls:
- pidfd_open()
- pidfd_getfd()
- pidfd_send_signal()
- New aspects to these existing syscalls:
- waitid() in its support of P_PIDFD
- clone()/clone3() in their support of CLONE_PIDFD
- poll()/epoll()/select() in their support for pidfds
- setns() in its support for pidfds
- pid introspection via /proc/[pid]/fdinfo/[pidfd]
It excludes:
- pidfdfs: pidfds are backed by the anon inode right now
- ioctls to retrieve namespace fds using a pidfd
- process_madvise()
Updates #5839.
PiperOrigin-RevId: 908341658
There are two issues being fixed: 1) checkAndPreventSharingOutsideTG() was
accessing t.fsContext without grabbing t.mu and thus causing a data race with
a concurrent unshare and 2) the concurrent unshare might present an incomplete
view of the shared fscontext and cause execve to incorrectly conclude that it
was shared outside the thread group.
Reported-by: [email protected]
Reported-by: [email protected]
PiperOrigin-RevId: 800327461
There is already some support for privileged executables before this change:
file capabilities were taken into account when creating new processes inside
the sandbox from external instigation (but not during execve(2)). set-user-id
and set-group-id bits were never taken into account, and the Sentry behaved
as if NO_NEW_PRIVS is always true. After this change, execve(2) and the
external Exec entry point both take the set-user(group)-id bits and file
capabilities into account.
Because NO_NEW_PRIVS can no longer be assumed to be always set, a couple of
extra checks to prevent privilege elevation during execve(2) are needed:
the presence of a ptracer and the use of a shared fsContext. Moreover,
execve had to be serialized with seccomp(2) when it is syncing filters to
all threads in a group. Serializing execve with PTRACE_ATTACH and seccomp
required some Task runState gymnastics.
Task dumpability is reset when privilege elevation takes place and privilege
elevation is denied for binaries living on nosuid mounts. To fix an old bug
where some aux vectors were populated using data from the old pre-execve
creds, the computation of the (file-privilege-augmented) creds during execve
now takes place before the stack for the new program is set up.
gvisor users who thus far have exec'd into the sandbox with UID as (sandbox)
root will lose the caps an all-powerful namespace root'd have if: 1) the binary
is a suid/guid binary 2) the owner of the binary is host root and there is
no mapping for host root in the host user namespace of the sandbox. To avoid
this surprise, the suid/sgid bits are ignored by default. Users can opt-in
via the --allow-suid flag.
One result of this change is that sudo now works inside the sandbox.
PiperOrigin-RevId: 794414101
Report panic just like Task.Active. Otherwise, it can report misleading errors
like: "panic: trying to use inactive address space?"
PiperOrigin-RevId: 791013732
Task.creds is documented as being "owned by the task goroutine", i.e. it can
only be mutated by the task goroutine, precluding the need for writer
synchronization. (AFAIK, no current Linux feature permits one task to change
another's credentials; capset(2) did before the introduction of VFS
capabilities, but gVisor doesn't support this. Libcs implement functions like
setresuid() by signaling every thread to execute the setresuid() syscall to
change their own credentials.) Prior to cl/185803179 and cl/205315612, the
mutex was needed to avoid data races on auth.Credentials fields; then prior to
cl/254989492, the mutex was needed to avoid data races on the auth.Credentials
pointer; now the mutex is not needed at all.
PiperOrigin-RevId: 777692758
From setpgid manpage,
EACCES - An attempt was made to change the process group ID of one
of the children of the calling process and the child had
already performed an execve(2) (setpgid(), setpgrp()).
This CL makes gVisor implement this rule and updates the exec test
suite accordingly.
TESTED: http://sponge2/7f364e8a-4f82-463e-ba62-79234c4d054d
PiperOrigin-RevId: 727095560
This allows "remote" locking of ThreadGroup.signalHandlers.mu without needing
to lock TaskSet.mu, analogously to Linux's lock_task_sighand().
This reveals a bug: kernel.Task.sendSignal[Timer]Locked() unintentionally
requires TaskSet.mu to be locked since it reads Task.exitState. To fix this,
use atomic memory operations on Task.exitState when required.
PiperOrigin-RevId: 681128063
Added a raw syscall points to all syscalls. Added schematized syscall
points to the following syscalls:
- read
- close
- socket
- connect
- execve
- creat
- openat
- execveat
Updates #4805
PiperOrigin-RevId: 446008358
Given that in most cases points are serialized to another process,
point data is now created diretly into protos.
As part of this change, infrastructure to track optional and context
fields was created to facilitate addition of lots of Points which is
needed for upcomming of changes.
Updates #4805
Currently the SST code is converting seccheck protos into SST protos
in the sentry before sending it to the API. After this change, SST
checker will be changed to send seccheck protos to the API and the
API then converts these into SST on the way to pubsub.
PiperOrigin-RevId: 442688320
This reduces confusion with context.Context (which is also relevant to
kernel.Tasks) and is consistent with existing function kernel.LoadTaskImage().
PiperOrigin-RevId: 342167298
Our "Preconditions:" blocks are very useful to determine the input invariants,
but they are bit inconsistent throughout the codebase, which makes them harder
to read (particularly cases with 5+ conditions in a single paragraph).
I've reformatted all of the cases to fit in simple rules:
1. Cases with a single condition are placed on a single line.
2. Cases with multiple conditions are placed in a bulleted list.
This format has been added to the style guide.
I've also mentioned "Postconditions:", though those are much less frequently
used, and all uses already match this style.
PiperOrigin-RevId: 327687465
The current task can share its fdtable with a few other tasks,
but after exec, this should be a completely separate process.
PiperOrigin-RevId: 314999565
FD table now holds both VFS1 and VFS2 types and uses the correct
one based on what's set.
Parts of this CL are just initial changes (e.g. sys_read.go,
runsc/main.go) to serve as a template for the remaining changes.
Updates #1487
Updates #1623
PiperOrigin-RevId: 292023223
This renames FDMap to FDTable and drops the kernel.FD type, which had an entire
package to itself and didn't serve much use (it was freely cast between types,
and served as more of an annoyance than providing any protection.)
Based on BenchmarkFDLookupAndDecRef-12, we can expect 5-10 ns per lookup
operation, and 10-15 ns per concurrent lookup operation of savings.
This also fixes two tangential usage issues with the FDMap. Namely, non-atomic
use of NewFDFrom and associated calls to Remove (that are both racy and fail to
drop the reference on the underlying file.)
PiperOrigin-RevId: 256285890
We don't actually support core dumps, but some applications want to
get/set dumpability, which still has an effect in procfs.
Lack of support for set-uid binaries or fs creds simplifies things a
bit.
As-is, processes started via CreateProcess (i.e., init and sentryctl
exec) have normal dumpability. I'm a bit torn on whether sentryctl exec
tasks should be dumpable, but at least since they have no parent normal
UID/GID checks should protect them.
PiperOrigin-RevId: 251712714
Based on the guidelines at
https://opensource.google.com/docs/releasing/authors/.
1. $ rg -l "Google LLC" | xargs sed -i 's/Google LLC.*/The gVisor Authors./'
2. Manual fixup of "Google Inc" references.
3. Add AUTHORS file. Authors may request to be added to this file.
4. Point netstack AUTHORS to gVisor AUTHORS. Drop CONTRIBUTORS.
Fixes#209
PiperOrigin-RevId: 245823212
Change-Id: I64530b24ad021a7d683137459cafc510f5ee1de9
