Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document possible sandbox restriction #370

Conversation

brandsimon
Copy link

As explained here: #279 (comment)_
I document this, since it is an information I wanted when first having contact with this tool.
Besides that, I had a lot of fun with it, thank you to all of the contributors!

@rh-atomic-bot
Copy link

Can one of the admins verify this patch?
I understand the following commands:

  • bot, add author to whitelist
  • bot, test pull request
  • bot, test pull request once

@brandsimon
Copy link
Author

Since nothing happened here, I am not sure I missed something. Do I need to tell the bot a command?

@alexlarsson
Copy link
Collaborator

I don't understand this addition. The section you added to talks about the security of bubblewrap itself on a system. I.e. as a sysadmin i need to consider: is there an increased risk in installing the bwrap package on a system (it can be setuid root after all).

What does this have to do with browsers or other apps restricting themselves?

@smcv
Copy link
Collaborator

smcv commented Jun 30, 2020

It's true to say that for programs like web browsers, which aim to enforce a security boundary within themselves (between the UI and the web content), a program running inside a bubblewrap sandbox is less able to enforce that security boundary than a program running on the host system.

However, it's deeply misleading to say that in a paragraph that is otherwise talking about whether bubblewrap undermines the security boundary between ordinary users and root, or between one user and another. The Security section of the README is currently only talking about this security boundary, and the bubblewrap vulnerabilities that were fixed in the past, like CVE-2020-5291, were flaws in this boundary.

If you want the README to talk about both of those security boundaries, then it needs to be as clear as possible which one you're talking about at any given moment.

There is a third interesting security boundary, between the code that is run inside the bubblewrap sandbox and the code that runs outside. Enforcing this boundary is not bubblewrap's job: it provides mechanisms that a caller could use to enforce this boundary, but not all callers even want to do that, and bubblewrap does not force them to. For example, most Flatpak apps are designed to protect processes outside the sandbox, but a few Flatpak apps like gnome-builder are designed to be able to be allowed to execute arbitrary code outside the sandbox.

@brandsimon brandsimon force-pushed the sbr/document_sandbox_restriction branch from 5fc0889 to 16190ac Compare July 11, 2020 13:26
@brandsimon
Copy link
Author

I agree with you, valid point! I changed the PR and split the two sections.

@brandsimon brandsimon force-pushed the sbr/document_sandbox_restriction branch 5 times, most recently from e1d194c to 3ed6a20 Compare March 19, 2023 19:24
@brandsimon
Copy link
Author

I rebased the branch and reworked the section. (Thank you @hartwork for your help).
Please let me know, if you want any further changes.

Signed-off-by: Simon Brand <simon.brand@postadigitale.de>
@brandsimon brandsimon force-pushed the sbr/document_sandbox_restriction branch from 3ed6a20 to 4b8d81a Compare March 21, 2023 21:31
@smcv
Copy link
Collaborator

smcv commented Feb 15, 2024

This has conflicts with #560, which I'm unable to resolve because the submitter did not give permission for bubblewrap maintainers to force-push to their branch, so I've pushed a slightly re-worded version as #621.

@smcv smcv closed this Feb 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants