[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [CONTRIBUTE] [DONATE]

System-wide sandboxing framework - sandbox-app-launcher

Thanks. Missed that one. Answered just now.

Saw this “new” feature being upstreamed. Don’t know how useful it can be for the sandbox:

https://www.phoronix.com/scan.php?page=news_item&px=2021-Unprivileged-Chroot

1 Like

Mount namespaces / AppArmor provide greater flexibility for us.

1 Like

Wouldn’t this be better suited in run_program()? Those chmod calls will only execute during setup; it won’t help if something messes up the permissions after setup.

1 Like
1 Like

Indeed. User would have to re-run setup, which is bad usability. Would be better if we could fix that automagically for the user.

In theory, yes. But during run_program() sandbox-app-launcher is run as user, not root. Therefore I don’t see how that’s possible. If a have a solution, please implement or let me know.

I have one idea that would be doable, though.

At the moment the tests during setup() look like this:

  if ! [ "$(stat -c %a "${shared_dir}")" = "1777" ]; then
    chmod 1777 "${dir}"
  fi

I.e.

  1. Test if already done.
  2. Do whatever needed not already done.

What could be done when running as user, without root, during run_program() is instead:

  1. Test if already done.
  2. If root, do it if not yet done. | If user, notify user and error exit.
run_if_root() {
  if [ "$sal_is_run_with_root" = "true" ]; then
    "$@"
  else
    echo "ERROR: The setup for this program is incomplete. To fix, please execute:

sudo sandbox-app-launcher setup ${app_name}

(Debugging information: $@)" >&2
    exit 1
  fi
}

if [ "$(id -u)" = "0" ]; then
  sal_is_run_with_root=true
fi

if ! [ "$(stat -c %a "${shared_dir}")" = "1777" ]; then
  run_if_root chmod 1777 "${dir}"
fi

What do you think?

1 Like

Merged.

That would be a good idea.

1 Like
1 Like
1 Like

I implemented a way to stub SIOCGIFHWADDR (and other syscalls if the need arises) with LD_PRELOAD.

I haven’t created a pull request yet because I want to know what you think of it. This will prevent apps using SIOCGIFHWADDR (like Telegram) from dying without actually exposing the MAC address. Right now, it just exits with a return code of 0 but in the future, we could make it return a legitimate MAC address shared amongst all sandbox-app-launcher users.

1 Like

grep -qE “NAME=“Debian GNU/Linux”|NAME=“Ubuntu”” /etc/os-release

What do you think about…

grep --quiet --invert-match --extended-regexp 'NAME="Debian|NAME="Ubuntu' /etc/os-release

Good? Better?

1 Like

All merged.

On a second thought… With the goal of code simplicity… Does sandbox-app-launcher get involved with privacy? Overextending project scope? Is that the right level to handle privacy issues?

If privacy matters, use a (Whonix or other) VM. Then it’s not a real hardware serial.

1 Like

Much better.

Sandboxing / permission models are fundamentally involved with privacy. If not, you could also make an argument for removing the camera, webcam, etc. permissions too. I don’t think restricting access to identifiers would be out of scope.

1 Like

How should we handle updates to the seccomp filter? Currently, the binaries won’t be recompiled if we were to update it. Could we move the seccomp filter generation into an apt install script that’s executed on every update? This would also simplify the main script a bit.

1 Like
1 Like

Improved in git master.

I see. For microphone, webcam I see a very strong rationale. Nobody wants a compromised application that doesn’t have legitimate use for these devices to turn these on after application compromise. One of the worse possible privacy breaches. MAC addresses have a lot lower severity, well, at least in a VM.

Feasible to blacklist enough identifiers due or https://www.whonix.org/wiki/VM_Fingerprinting making that infeasible?

There’s tons of hardware identifies. (Many listed here: https://www.whonix.org/wiki/Protocol-Leak-Protection_and_Fingerprinting-Protection) Feasible to go for it or would that be similar to re-inventing a VM or full emulation?

1 Like

We don’t have to blacklist identifiers since our AppArmor and seccomp policy are default-deny. Identifiers must be specifically whitelisted. In the case of MAC addresses, the issue was that I didn’t want to whitelist it.

We have fine-grained restrictions on filesystems like /sys and /proc which kills most identifiers already. machine-id is already spoofed (https://github.com/madaidan/sandbox-app-launcher/blob/master/usr/share/sandbox-app-launcher/machine-id) and we could spoof other potential identifiers in a similar fashion. It wouldn’t be very difficult.

1 Like

Then I guess, go for it.

Merged.

These are application specific or for all applications?
Yes. Moving to Debian maintainer postinst script would be appropriate if for all applications.
(Even if application specific this could be considered.)
Getting things out of the main script can also be good.

1 Like

All applications.

1 Like
[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Contributors] [Investors] [Priority Support] [Professional Support]