It was time when the developer came in and clarified everything in the posts above. There is literally no valid reason to not recommend this. In fact, it makes a lot more sense to recommend this than Kicksecure because secureblue is based on a sane distribution and not Debian.
7 Likes
I agree, Kicksecure doesnât do anything special compared to Secureblue and is much worse in many cases. The Kicksecure recommendation should be removed imo. Whonix still has a use case for anonymity with their gateway-workstation VM setup but if a project can do something similar with Secureblue then it would easily obselete Whonix.
1 Like
Agree but removing kicksecure should be a separate discussion.
1 Like
Yeah I was gonna start one once Secureblue is recommended.
didnât run0 rely on pkexec?
No, and we remove pkexec from secureblue too 
3 Likes
The remaining suid binary on secureblueâs main/userns systems is polkit-agent-helper-1, which will go away with the merge of this PR:
3 Likes
Nice. Are these the only binaries where you replaced SUID with capabilities? Iâd like to do something similar on my (arch) system.
Also @RoyalOughtness are there plans for shipping bubblejail profiles for programs and enabling them by default?
+1 but there should be a guide first on how to safely install and run software in Secureblue. Flatpak alone isnât very good depending on the program due to e.g. device permissions not being flexible enough (device=all is bad and some apps wonât run without it), and idk about how distrobox can be secured (I donât use it).
There also has to be a documented way on how to safely run X11-only programs. Some programs that PG recommends are X11-only e.g. SimpleX or default to X11 and are by default broken if X11 isnât available (e.g anything electron). Standard Xwayland isnât safe. I donât think itâs a problem that Secureblue can fix themselves but itâs still a problem and users should be informed on how to solve it.
Offtopic but Kicksecure is still a very good option as VMs for the truly paranoid, even if Secureblue is better as a host OS.
Off-topic
Canât one use Flatseal to solve that issue?
1 Like
Off-topic
No. Device permissions are limited to dri, input, kvm, shm, all. If you add custom paths to the sandbox, itâs (AFAIK) a regular bwrap --bind or --ro-bind and wonât work for devices
1 Like
Nice. Are these the only binaries where you replaced SUID with capabilities?
Yes
Also @RoyalOughtness are there plans for shipping bubblejail profiles for programs and enabling them by default?
Not at the moment because the current #1 priority is SELinux confinement for chromium, bwrap, and flatpak.
+1 but there should be a guide first on how to safely install and run software in Secureblue.
Youâre looking for ujust audit-secureblue
anything electron
Most electron apps work fine on wayland-only systems. Aside from that, if a program only supports X11, users are encouraged to find an alternative.
1 Like
Sorry if Iâm missing something but doesnât this simply check if all the hardening measures were correctly applied⌠?
So, is there no interest at all in supporting running X11 apps securely in the future? Could probably launch something like xwayland-satellite inside each sandbox, set $DISPLAY accordingly and it should just work (mostly).
I know, my problem with this is that these apps are broken by default which isnât good. If functionality that people expect to just work is broken, then the fix should also be documented, even if you think itâs trivial.
Sorry if Iâm missing something but doesnât this simply check if all the hardening measures were correctly applied⌠?
It also gives suggestions for hardening flatpaks with overly permissive permissions. Eventually we want it to give suggestions for all findings
So, is there no interest at all in supporting running X11 apps securely in the future?
I wouldnât say thereâs no interest, just that itâs not a priority. X11 is going away and Xwayland is already disabled by default in secureblue. Investing time in a technology thatâs being phased out when there are bigger fish to fry just doesnât seem like a great use of time.
these apps are broken by default which isnât good
I run an X11/Xwayland-less session and have tested numerous electron flatpaks, all have worked ootb with no workarounds. Other secureblue users have reported the same.
It would help immensely if you provided specific examples.
2 Likes
Ok, my point here is more about running things that arenât flatpaks and/or wouldnât work in a default configuration, or would normally require decreasing the security of the OS (e.g. by enabling Xwayland without taking any extra measures to secure it).
Iâm not saying that you should make a guide about t his if itâs not in the scope of the project, but before Secureblue is recommended PG should document how the recommended apps can be run in the distribution, in a way that doesnât break the security model that you are aiming for.
EDIT: also, some flatpaks do need âbadâ permissions to work correctly. Bottles for instance breaks if you deny device=all.
Yes, itâs been âgoing awayâ for 5 years or so. Right now I donât think that itâs feasible for most people to not use X11. Definitely not anyone who plays games as the WINE Wayland driver is not mature yet, Steam still relies on X11 etc.
Plus many apps donât support native wayland yet even though itâs improving.
At the very least, I think that it would be safest to consider unsetting $DISPLAY outside sandboxes even when Xwayland is enabled, so that the user doesnât accidentally run a X11 app unsandboxed which would lead to a sandbox escape.
Element, Signal and Discord are examples that come to mind. Element works if you use the appropriate flag but Discord doesnât support Wayland at all. Signal doesnât work at all I think⌠Iâve been successful in running Signal under wayland on my system but only the Beta version and that isnât available as a flatpak.
1 Like
by enabling Xwayland without taking any extra measures to secure it
but before Secureblue is recommended PG should document how the recommended apps can be run in the distribution
If a recommended app requires Xwayland and an alternative is available that doesnât, then the recommendation should be adjusted. Adding back Xwayland is opening a can of worms. And again, hardening that can of worms, while in scope, is not a priority.
plays games
Gaming and security on desktop linux donât play nice with each other to begin with. Enabling Xwayland is just one of the many bits of hardening someone might want to undo to improve gaming compatibility or performance (e.g. dehardening our ptrace scope setting, which enables anticheat support). So while gaming on secureblue is very much supported, hardening and gaming are largely opposite goals (even simple stuff like enabling cpu mitigations, init_on_alloc, or nosmt which reduce perf).
Element
You should avoid the element electron client to begin with if you care about security. Youâre much better off using the webapp in an up-to-date browser instead of an old, neutered chromium via electron.
Signal
Even moreso, if you care about security you shouldnât touch the signal electron desktop app in any form (flatpak/deb/etc) with a 10 foot pole.
Discord
The discord webapp works well
1 Like
Iâm not sure about battleye but EAC worked well for me with kernel.yama.ptrace_scope=2
Disabling SMT can actually improve performance depending on the game. Itâs true that some of the hardening reduces performance but the drops arenât that big depending on oneâs hardware and the game. I think itâs perfectly feasible to game on a hardened system, given that oneâs hardware is recent/powerful enough.
I donât want to derail the thread by discussing âelectron good/badâ again but at least itâs worth noting that Element and Signal donât use EOL versions of Electron like some other apps out there and therefore should have the latest security updates.
1 Like
Just buy an intel cpu without hyperthreading ;p
Signal work-ish under Wayland, you can force it to be Wayland (I use it inside of a distrobox). Signalâs repo still apparently targets Ubuntu 16.04, which makes me question why???
just a side note, most latest gen cpus that have hardware mitigations for spectre, and mitigations=auto,nosmt doesnât disable hyperthreading for those cpus
We do give users with latest gen hardware the option to force smt off regardless of their hardware mitigations, but by default smt is off for known-affected hardware and left on otherwise.
Doesnât nosmt disable hyperthreading, as smt is the non intel name for the same principle?
Edit, p.s. welcome to the forum btw, good to have you on board