tips

dev-docs/howtoguides/troubleshoot_apt_news_security_confinement.md

@@ -139,10 +139,70 @@ If whatever incorrect behavior that you were observing is now gone, then it's li
 
 The exact meaning of each sandboxing feature is well documented upstream, in the [systemd.exec sandboxing](https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html#Sandboxing) section of the manpage. But as with apparmor, be mindful of differences between Ubuntu Releases: not all features from the latest releases will be available in, say, Ubuntu Xenial, for example.
 
+There is one additional troubleshooting tip that can be helpful, and that is to run any command with specific sandboxing features enabled.
+
+For example, let's try the `PrivateTmp` feature. First, let's create a file in `/tmp`:
+```
+touch /tmp/my-file
+```
+
+It should be visible to you. Let's check with `ls -la /tmp/my-file`:
+```
+-rw-r--r-- 1 root root 0 jan  3 16:31 /tmp/my-file
+```
+
+Now let's try it with the `PrivateTmp` restriction disabled, first. The command is:
+```
+systemd-run -qt -p PrivateTmp=no ls -la /tmp/my-file
+```
+
+And the output will be:
+```
+-rw-r--r-- 1 root root 0 jan  3 16:31 /tmp/my-file
+```
+
+What happens if we enable the restriction? The command now is:
+```
+systemd-run -qt -p PrivateTmp=yes ls -la /tmp/my-file
+```
+
+And we get:
+```
+/usr/bin/ls: cannot access '/tmp/my-file': No such file or directory
+```
+
+Interesting! What if we create a file in `/tmp` with the restriction enabled, will it still be there once the command finishes? Let's try:
+```
+systemd-run -qt -p PrivateTmp=yes touch /tmp/other-file
+```
+
+And when we check with `ls -la /tmp/other-file`:
+```
+ls: cannot access '/tmp/other-file': No such file or directory
+```
+
+That's what `PrivateTmp=yes` means: the service will get a fresh and empty `/tmp` directory when it starts, and that will be gone when it finishes.
+
+These restrictions can be specified multiple times in the `systemd-run` command line with the `-p` parameter.
+
+Here is another example: let's block the `CAP_NET_RAW` capability, and try the `ping` command:
+```
+systemd-run -qt -p CapabilityBoundingSet=~CAP_NET_RAW ping -c 1 1.1.1.1
+```
+
+That will show nothing, but the exit status `$?` is `203`, so something failed. If we check the journal, we will see:
+```
+jan 03 16:36:31 nsnx2 systemd[1]: Started run-u3002.service - /usr/bin/ping -c 1 1.1.1.1.
+jan 03 16:36:31 nsnx2 (ping)[575067]: run-u3002.service: Failed to execute /usr/bin/ping: Operation not permitted
+jan 03 16:36:31 nsnx2 (ping)[575067]: run-u3002.service: Failed at step EXEC spawning /usr/bin/ping: Operation not permitted
+jan 03 16:36:31 nsnx2 systemd[1]: run-u3002.service: Main process exited, code=exited, status=203/EXEC
+jan 03 16:36:31 nsnx2 systemd[1]: run-u3002.service: Failed with result 'exit-code'.
+```
+
 
 ## Cheat sheet
 
-Here are a few handful Apparmor tips.
+Here are a few handful Apparmor and Systemd tips.
 
 | What                                    | How                                    |
 |-----------------------------------------|----------------------------------------|
@@ -152,4 +212,4 @@ Here are a few handful Apparmor tips.
 | List loaded profiles                    | `sudo aa-status`                       |
 | Check apparmor logs                     | `sudo dmesg -wT \| grep apparmor=`     |
 | Run a command under an apparmor profile | `sudo aa-exec -p <profile> <cmd>`      |
-
+| Run a command with a systemd sanboxing property | `sudo systemd-run -qt -p <property> <cmd>` |