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
L2 MTU includes both payload and ethernet header. gVisor has supported setting
data link layer MTU, it will be up to users to set up proper value for a
device's MTU if a larger value is expected.
By doing the change, gVisor will be consistent with runc:
```shell
# runc
root@cec4d7238802:/# ip link set dev lo mtu 1234
root@cec4d7238802:/# ip link list dev lo
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 1234 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
# runsc before the change.
root@7cd89278d414:/# ip link set dev lo mtu 1234
root@7cd89278d414:/# ip link list dev lo
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 1220
link/loopback 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
# runsc after the change.
root@e811c5851226:/# ip link set dev lo mtu 1234
root@e811c5851226:/# ip link list dev lo
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 1234
link/loopback 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
```
PiperOrigin-RevId: 684746090
The error code is based on the runc's behavior:
```shell
# ip link set dev br0 master br0
Error: Can not enslave a bridge to a bridge.
# echo $?
2
```
Reported-by: [email protected]
PiperOrigin-RevId: 679761515
IFLA_IFNAME is used to set an interface's name when being used
with RTM_NEWLINK and RTM_SETLINK. RTM_NEWLINK is the preferred way, it
is backwards compatible with RTM_SETLINK. For gVisor, when RTM_SETLINK is
introduced, it shall just share the implementation.
PiperOrigin-RevId: 647833657
