Commit Graph

10 Commits

Author SHA1 Message Date
Christian Blichmann
d451478e26 Change license link to HTTPS URL
PiperOrigin-RevId: 424811734
Change-Id: If5ea692edc56ddc9c99fd478673df41c0246e9cc
2022-01-28 01:39:09 -08:00
Christian Blichmann
ca6ec4337d Add workaround for active Tomoyo LSM
Recenly, Debian based distribution kernels started activating the Tomoyo Linux
Security Module by default. Even if it is not used, this changes the behavior
of `/dev/fd` (pointing to `/proc/self/fd` by default), which Sandbox2 needs during
`execveat()`.

As a result, Sandbox2 and Sandboxed API always fail without one of the following
conditions
- `/proc` mounted within the sandboxee
- `/dev` mounted
- `/dev/fd` symlinked to `/proc/self/fd` in the sandboxee's mount namespace

Some code pointers to upstream Linux 5.12.2:
- https://elixir.bootlin.com/linux/v5.12.2/source/fs/exec.c#L1775
- https://elixir.bootlin.com/linux/v5.12.2/source/security/tomoyo/tomoyo.c#L107
- https://elixir.bootlin.com/linux/v5.12.2/source/security/tomoyo/domain.c#L729

To find out whether your system has Tomoyo enabled, use this command, similar to
what this change does in code:

```
$ cat /sys/kernel/security/lsm | grep tomoyo && echo "Tomoyo active"
capability,yama,apparmor,tomoyo
Tomoyo active
```

The config setting `CONFIG_DEFAULT_SECURITY` controls which LSMs are built into
the kernel by default.

PiperOrigin-RevId: 372919524
Change-Id: I2181819c04f15f57d96c44ea9977d0def4a1b623
2021-05-10 07:04:04 -07:00
Wiktor Garbacz
3d0fa1f891 Replace GetNode with ResolvePath in Mounts
Now unwinding will properly handle binaries inside bind-mounted directories.

Drive-by:
 - Get rid of n^2 path handling
 - Get rid of namespace alias
PiperOrigin-RevId: 358353666
Change-Id: Ieec7690ec6a1ae6d358de375220566b69e8cb094
2021-02-19 00:43:34 -08:00
Christian Blichmann
f6c3db4c6e Replace sapi::Status with absl::Status
PiperOrigin-RevId: 297614681
Change-Id: I89fe1357a172ed4d28df6dd84b80fee364ce1c14
2020-02-27 09:24:12 -08:00
Christian Blichmann
441201884a Update license header with recommended best practices
PiperOrigin-RevId: 290250533
Change-Id: Ic34b253446463cf971a055b70a242df93a598ee3
2020-01-17 05:05:29 -08:00
Wiktor Garbacz
1673ade4e4 Remount chroot as read-only
PiperOrigin-RevId: 280394655
Change-Id: I1490b7dfbbca3d91f5efb4dd5800397c9da57da8
2019-11-14 03:51:26 -08:00
Kevin Hamacher
4da8f68aa8 Rework stacktrace mounttree logic
The previous one was not quite correct in cases where the outside binary path
did not match the inside path. This should be fixed with this.

PiperOrigin-RevId: 276075886
Change-Id: I1c7c4fa0191960437a2d2360b805c7098b1407c9
2019-10-22 09:05:33 -07:00
Christian Blichmann
276b7efc92 Internal change.
PiperOrigin-RevId: 265057217
Change-Id: Id00c867b373dbe8c9112c23ef4b0300ed3ca9e5b
2019-08-23 08:08:51 -07:00
Sandboxed API Team
f29a5a81ed Print final FS mounts in sandboxee's chroot
After all requested filesystem mounts are fully mounted under a sandboxee's virtual chroot, print a list of the outside paths and a list of the inside chroot paths that the outside paths are mapped to. This provides a valuable insight while debugging sandboxed binaries.

PiperOrigin-RevId: 247130923
Change-Id: I42b4b3db68d826587c0fe8127aabbead38bc6f20
2019-05-07 18:30:13 -07:00
Christian Blichmann
177b969e8c
Sandboxed API OSS release.
PiperOrigin-RevId: 238996664
Change-Id: I9646527e2be68ee0b6b371572b7aafe967102e57

Signed-off-by: Christian Blichmann <cblichmann@google.com>
2019-03-18 19:00:48 +01:00