When will we get secure desktop OSes? (2018)(games.greggman.com)
games.greggman.com
When will we get secure desktop OSes? (2018)
https://games.greggman.com/game/secure-desktop-oses-when/
101 comments
I don't understand the responses in this thread. Does nobody want an OS with a permissions system where you can reliably control access to resources? Or strong app sandboxing by default to keep chrome from sniffing your files (allegedly, this is virus scanning)? There isn't any loss of freedom with those as long as your super user can modify it all - its a gain of freedom in that you can have some control over what your random proprietary programs are doing
No, most people don't want that.
The average HN reader does. If your business plan can thrive with 95% of your customers being developers, sysadmins, geeks, nerds, academics, people who remember what the first and second derivatives of space with regard to time mean, and the people who are associated with them... sure, go ahead. But we already are almost there with macos and chromeos and linux. We just need one more layer:
root can allow and rescind privs to
users who can allow and rescind privs to
applications
but the fact of the matter is, right now people not in the categories above do not like the tradeoff of thinking about permissions in exchange for more control. Microsoft and Apple could force it on them, but as soon as a convenience feature of "never think about this decision again" shows up, users will click on that and never think about it at all. Some people will click on things because they were promised a game, or porn, or wallpaper images of kittens.
The average HN reader does. If your business plan can thrive with 95% of your customers being developers, sysadmins, geeks, nerds, academics, people who remember what the first and second derivatives of space with regard to time mean, and the people who are associated with them... sure, go ahead. But we already are almost there with macos and chromeos and linux. We just need one more layer:
root can allow and rescind privs to
users who can allow and rescind privs to
applications
but the fact of the matter is, right now people not in the categories above do not like the tradeoff of thinking about permissions in exchange for more control. Microsoft and Apple could force it on them, but as soon as a convenience feature of "never think about this decision again" shows up, users will click on that and never think about it at all. Some people will click on things because they were promised a game, or porn, or wallpaper images of kittens.
Almost surely that will be coupled with an appstore and end the era of free computing for most people. It would be great if it didn't happen that way, but I don't see Apple or Microsoft doing it any other way.
Not really no, this would break just about every software workflow I use. My music production workflow relies on being able to arbitrarily send inputs and outputs between any other piece of software I want.
There isn't really any software I use that can exist in its own sandboxed bubble separate from everything else.
I've experienced this several times trying Android ports of Linux software I use, they're usually lacking features or configuration folders are inaccessible because of Android's sandboxing and permissions.
The last thing I want is for my desktop to be that way too.
There isn't really any software I use that can exist in its own sandboxed bubble separate from everything else.
I've experienced this several times trying Android ports of Linux software I use, they're usually lacking features or configuration folders are inaccessible because of Android's sandboxing and permissions.
The last thing I want is for my desktop to be that way too.
No, we don't. Stuff you don't trust and can't be bothered to publish source and engage with the community belongs in the browser. Native code is a privilege reserved for people who are friendly. As you can see from iOS and Android all the sandboxing does is screw over people working in good faith (termux, ish) and doesn't stop malware.
Termux has a solution that they refuse to adopt, use Java APIs from Android.
Android's use of Linux kernel is an implementation detail, trying to pretend otherwise only leads to pain.
Android's use of Linux kernel is an implementation detail, trying to pretend otherwise only leads to pain.
>use Java APIs from Android.
Considering termux is package mostly software written in c I'd love to hear how you expect them to do that.
Considering termux is package mostly software written in c I'd love to hear how you expect them to do that.
By doing like anyone else on Android does, by making use of JNI and NDK APIs, the actual Android ABIs.
In regards to C, Android NDK supports ISO C11 and ISO C++17 as of today.
Android is not Linux, just borrowed the kernel as implementation detail.
Naturally some folks don't get it, thus keep trying the broken road to use POSIX in Android, and that road ends in failure.
In regards to C, Android NDK supports ISO C11 and ISO C++17 as of today.
Android is not Linux, just borrowed the kernel as implementation detail.
Naturally some folks don't get it, thus keep trying the broken road to use POSIX in Android, and that road ends in failure.
I want an os that's useful, streamlined, and can run games without adding an asterisk. That basically locks me into Windows. I've heard lots of great excuses for why things are this way and noted the progress Steam has made in pushing forward gaming on Linux but ultimately there's always a wall or a compromise in what mainstream programs I can use and I'm not the sort of person who can feel good because the worse experience has principles. I don't mind if a job wants me to work with Linux, that's fine, but when I come home I don't want to have to think about edge cases or software equivalents.
That's fair, except for utility in my usage Windows runs less of the programs I want.
Linux users tend to prioritise software freedom, digital privacy, customisability, hackability and longevity, so will settle for it being a little less streamlined and being able to run 15k out of 18k Steam games, which is more than enough games for my enjoyment. Each to their own.
Linux users tend to prioritise software freedom, digital privacy, customisability, hackability and longevity, so will settle for it being a little less streamlined and being able to run 15k out of 18k Steam games, which is more than enough games for my enjoyment. Each to their own.
I wonder if less streamlined is still an issue. Yes, Linux has plenty of weird bugs and sharp corners, but since windows 8 or so, windows has at least as much of them. Wine gets at the point that it runs older windows software better than windows.
Games is still hit or miss, though.
Games is still hit or miss, though.
Things that used to work will get broken. The fact that taking a screenshot on Wayland took something like a decade to sort out speaks volumes as to the downsides of this approach.
It'll be worth it in the long term, but short term it'll probably hurt.
It'll be worth it in the long term, but short term it'll probably hurt.
> screenshot on wayland
Also note that the solution (at least in wlroots-based compositors) seems to allow any program running as the logged-in user to screenshot or record any portion of the screen; the same as on X.
Though flatpack apps need to use special permission that grants them access to only parts of your screen.
I think that's what we need. An app with a "firewall" for every security or privacy critical operation that prompts the user when it has to.
We can have that for the browser with e.g. uMatrix or uBlock origin and other extensions, or LittleSnitch on MacOS but it should be handled at the system (call) (kernel?) level I guess.
The user can then set up the rules he wants to so he doesn't always get prompted.
And for non technical users there have to be sensible defaults already in place. An example of not so sensible defaults are the default permissions of many flatpak apps.
And for privacy we need granular control, like on Android with something like XPrivacyLua. But it does pose some challenges, for example it makes it easy to just spoof your location and so on for an app. Personally I do think that the user has the right to do that though.
And for non technical users there have to be sensible defaults already in place. An example of not so sensible defaults are the default permissions of many flatpak apps.
And for privacy we need granular control, like on Android with something like XPrivacyLua. But it does pose some challenges, for example it makes it easy to just spoof your location and so on for an app. Personally I do think that the user has the right to do that though.
Agreed. Tools like Firejail and OpenSnitch go a long way towards this, but it could be better. There's also the matter of presenting this in a way that is useful to the average user .. by the time a user sees a third popup asking "Do you want to allow Firefox to access 23.12.99.8?" they will have been conditioned to always click [OK].
I really like alpine linux's goals i.e. Install only the things which are absolutely necessary on a hardened system. But as desktop you are seriously limited by its dependency on musl, Most common apps are dependent upon glibc and so you'll have to compile it against musl if that's even possible.
So the point being, We have secure desktop OSes but how much productivity are we ready to give up for that?
So the point being, We have secure desktop OSes but how much productivity are we ready to give up for that?
I want it, but not bad enough to live with the various inconveniences.
Sandboxing is a huge issue that plagues desktop operating systems. And sadly is it only one piece of the puzzle.
Android for example additionally has detailed SELinux policies and extensive compile time hardening.
You can sandbox the majority of your apps on desktop Linux today with two simple commands:
- sudo apt/dnf install firejail
- sudo firecfg
Project: https://github.com/netblue30/firejail
Intro Video: https://www.youtube.com/watch?v=N-Mso2bSr3o
Disclosure, I am a contributor to firejail.
Also if you are already using flatpaks, you can install flatseal to easily point and click which permissions you want:
https://www.flathub.org/apps/details/com.github.tchx84.Flats...
Lastly you can sandbox your systemd daemons:
https://www.freedesktop.org/software/systemd/man/systemd.exe...
Have fun!
You can sandbox the majority of your apps on desktop Linux today with two simple commands:
- sudo apt/dnf install firejail
- sudo firecfg
Project: https://github.com/netblue30/firejail
Intro Video: https://www.youtube.com/watch?v=N-Mso2bSr3o
Disclosure, I am a contributor to firejail.
Also if you are already using flatpaks, you can install flatseal to easily point and click which permissions you want:
https://www.flathub.org/apps/details/com.github.tchx84.Flats...
Lastly you can sandbox your systemd daemons:
https://www.freedesktop.org/software/systemd/man/systemd.exe...
Have fun!
Firejail is the solution to the author's concerns.
I only would suggest a whitelist based approach instead of a blacklist approach.
I only would suggest a whitelist based approach instead of a blacklist approach.
A whitelist/allowlist approach doesn't work for all programs, see this discussion about it: https://github.com/netblue30/firejail/issues/2070
This is the solution we need in all OS's.
Excellent work.
Excellent work.
I think the reality is that the average HN reader/developer and the general public want/need a device with requirements that are very far from each other and are very hard to integrate.
A chrome book like device that gets wiped every time it's started and downloads a clean OS so the user can browse the web, play games, and edit (remotely housed) documents would suit 90%+ of the world.
Perhaps developers should be using different OS from users.
A chrome book like device that gets wiped every time it's started and downloads a clean OS so the user can browse the web, play games, and edit (remotely housed) documents would suit 90%+ of the world.
Perhaps developers should be using different OS from users.
Sure, it would suit 90% of the world, but at what cost? It would further turn computers & the internet into a passive medium, one meant to be consumed. It might have some short term security benefits for users, but in the long term, that's going to lead to even less tech literacy, ultimately only benefiting FAANG.
I don’t see that as strictly necessary. You don’t need root access or gcc to be a creator - think of geocities: that was always someone else’s computer and would be perfectly compatible with the most locked down chromebook
TFTP Net Booting or its modern variant PXE.
Qubes OS is perfectly usable if you are a technical person and describes itself as "reasonably secure" https://www.qubes-os.org/ . They take the security challenges of all the layers of the onion pretty seriously and have built a system that works well for many threat models. You do have to put up with some inconvenience (eg copying and pasting between vms etc) but you get a lot for that.
Qubes looks great if you have a static separation of concerns you can plan for in advance. My instinct is that VMs in general are a improvised way to implement the principle of least privilege.
I believe what we all want, but most of us don't realize yet, is the ability to generate a whitelist (capability) on the fly, and hand it off to an otherwise completely sandboxed application.
This allows you to reason directly on what resources you're willing to trust to the process. By allowing a concrete manner of limiting side effects, you ensure that no matter how buggy, or even malicious, the process is, it can't modify anything else.
This allows a level of security we haven't had since 2 floppy MS-DOS machines with write protect tabs that worked.
I believe what we all want, but most of us don't realize yet, is the ability to generate a whitelist (capability) on the fly, and hand it off to an otherwise completely sandboxed application.
This allows you to reason directly on what resources you're willing to trust to the process. By allowing a concrete manner of limiting side effects, you ensure that no matter how buggy, or even malicious, the process is, it can't modify anything else.
This allows a level of security we haven't had since 2 floppy MS-DOS machines with write protect tabs that worked.
Agreed. The main catch for most people who should be using it may be to first get hardware with full support to install it on. The range of machines with TPM and the appropriate virtualization and memory control capabilities is long enough, at least for laptops, but to additionally neuter Intel ME (AMD PSP still unsolvable for now?) and install open firmware and still have all of the functionality needed, is a pretty high bar.
Then again, even without that last distance, at least it would improve the situation in many cases.
I think Greggman is mostly wrong the software which people want to run is not available to run on Qubes, but one probably has to admit that stuff not available in the repositories of the Template systems could be a bit arduous to configure. Fancy Windows games demanding a powerful GPU seems a bit like asking for trouble that way. Probably both doable and acceptably practical with enough motivation though.
Then again, even without that last distance, at least it would improve the situation in many cases.
I think Greggman is mostly wrong the software which people want to run is not available to run on Qubes, but one probably has to admit that stuff not available in the repositories of the Template systems could be a bit arduous to configure. Fancy Windows games demanding a powerful GPU seems a bit like asking for trouble that way. Probably both doable and acceptably practical with enough motivation though.
Yeah. In my experience it has worked great on things like Lenovo Thinkpads and I also have it running on a Pureism Librem 15. It's sometimes a bit inconvenient but is totally usable as a daily main work OS (I used to use it as such).
This [1] is a good read.
[1] https://invisiblethingslab.com/resources/2014/Software_compa...
[1] https://invisiblethingslab.com/resources/2014/Software_compa...
I'm personally very enthusiastic about the security model of Fuchsia:
https://fuchsia.dev/fuchsia-src/concepts/principles/secure
https://www.youtube.com/watch?v=gIT1ISCioDY
https://fuchsia.dev/fuchsia-src/concepts/principles/secure
https://www.youtube.com/watch?v=gIT1ISCioDY
I'm curious how they deal with things like images you want to download, edit, put into documents, upload/download to the web, etc. Perhaps it's all based on the notion you'll use a web browser for all of that.
If you want to get there, I wouldn't start from here.
The problem is, from the status quo we have today it's hard to see how we'd get to a point of security without sacrificing general purpose computing.
After all, it's either possible for the user to promote an application to equal the power of the OS, or it isn't.
Oh, sure, you could make it mandatory to ask permission before getting that power. But many security people think we need a system that's secure even in the face of a gullible user who will click through any warning. And there are thousands of applications that enjoy unlimited permissions today; for them, asking for maximum permissions will be the path of least resistance.
The alternative is the iPhone approach: Every app in a sandbox, and no way out of the sandbox even with the user's consent.
The problem is, from the status quo we have today it's hard to see how we'd get to a point of security without sacrificing general purpose computing.
After all, it's either possible for the user to promote an application to equal the power of the OS, or it isn't.
Oh, sure, you could make it mandatory to ask permission before getting that power. But many security people think we need a system that's secure even in the face of a gullible user who will click through any warning. And there are thousands of applications that enjoy unlimited permissions today; for them, asking for maximum permissions will be the path of least resistance.
The alternative is the iPhone approach: Every app in a sandbox, and no way out of the sandbox even with the user's consent.
There are different methods of security, one where you assume the user is trusted but that the programs are not and one where you assume the user and the programs are not trusted.
iOS is the second version. Linux with flatpak and SELinux is the first one. It is certainly possible to secure Linux a lot while still allowing the user to tweak whatever they want. There is a tool called flatseal which lets you adjust the sandbox settings for any Flatpak.
iOS is the second version. Linux with flatpak and SELinux is the first one. It is certainly possible to secure Linux a lot while still allowing the user to tweak whatever they want. There is a tool called flatseal which lets you adjust the sandbox settings for any Flatpak.
Well, the problem is that many desktop workflows require data passing through many apps. How would you do that on the iOS model?
iOS has 2 solutions to this. They have a push models where you “share” the file to the next app you want to use. And they also have a traditional file store model where all apps can request to save and request to load files.
Critically, apps can not directly read your files, they can show a button which will open the OS file picker and the user can pick a file to open which then provides access to the app.
This means that opening a game does not instantly expose all of your sensitive files.
Critically, apps can not directly read your files, they can show a button which will open the OS file picker and the user can pick a file to open which then provides access to the app.
This means that opening a game does not instantly expose all of your sensitive files.
> Critically, apps can not directly read your files, they can show a button which will open the OS file picker and the user can pick a file to open which then provides access to the app.
Unfortunately this model breaks down for any kind of file type that doesn't simply consist of a single, atomic file, e.g. various constellations of media files (playlists, subtitles, multi-part videos), multi-part archives, HTML files, georeferenced imagery with sidecar files, etc. etc.
Unfortunately this model breaks down for any kind of file type that doesn't simply consist of a single, atomic file, e.g. various constellations of media files (playlists, subtitles, multi-part videos), multi-part archives, HTML files, georeferenced imagery with sidecar files, etc. etc.
iOS apps can be given access to files and folders created in other apps. I have no idea when this was added, I didn't use iOS between 3.x and 14.x, but it's there.
https://juno.sh/ios-file-system/ for some info about how it works from the perspective of an application that might need to access other apps' data.
https://juno.sh/ios-file-system/ for some info about how it works from the perspective of an application that might need to access other apps' data.
This article is from 2018.
Many of the points made in this post have since been addressed by macOS, and continue to be addressed.
In fact, some of the issues the author complains about were addressed by the macOS in 2018.
Many of the points made in this post have since been addressed by macOS, and continue to be addressed.
In fact, some of the issues the author complains about were addressed by the macOS in 2018.
Making it an OS more hated by the day.
I mean, that’s actually a fair observation, at least on HN. A lot of people on HN do complain about the changes.
There’s a tradeoff between security and convenience. Making something more secure is, essentially, making it harder to use for undesired use cases. The side effect is inevitably that it also makes it harder to use for legitimate use cases.
There’s a tradeoff between security and convenience. Making something more secure is, essentially, making it harder to use for undesired use cases. The side effect is inevitably that it also makes it harder to use for legitimate use cases.
[deleted]
I have a suspicion that the most vocal complainers don't even use it.
I am sadly typing this on a mac right now and it's a constant pain versus my main linux system (which is in a lot of aspects also a big pain when I think about how simply everything worked in win98). Have to right-click > open every other app I use, gatekeeper blocking apps for no good reason, etc etc
I really like the way macOS is getting more secure.
It just seems like good engineering if nothing else - why do applications get to access devices by default?
It just seems like good engineering if nothing else - why do applications get to access devices by default?
does macOS have any way of detecting/showing/preventing screenshots/screenrecordings? I'm not sure if newer macOS versions have that kind of fine-grained control over privacy.
Yes, there is the "Screen recording" parameter in Security & Privacy settings.
Also, I remember getting some issues with apps like "Bartender 3" that requires taking screenshots regularly to rearrange the top bar (!!) [1]. Never accepted that and moved to another app...
[1] About the "Screen Recording" permission for "Bartender 3": https://www.macbartender.com/Screen-Recording-Permission/
Also, I remember getting some issues with apps like "Bartender 3" that requires taking screenshots regularly to rearrange the top bar (!!) [1]. Never accepted that and moved to another app...
[1] About the "Screen Recording" permission for "Bartender 3": https://www.macbartender.com/Screen-Recording-Permission/
We're still a few years away, Genode and Fuchsia are currently my odds on favorites to deliver a system based on capabilities. (Not the limited kind used in cell phones, the real ones, with granularity down to the single resource handle)
Such a system can be just as easy to use, but secure in enforcing the will of the user.
Such a system can be just as easy to use, but secure in enforcing the will of the user.
That is a problem. You shouldn't trust apps. You should haven't to trust apps any more than you should have to trust webpages. Apps can be just as evil as a webpage. In fact apps can be more evil because at the moment they aren't sandboxed on Mac or Windows or Linux so they can do far more damage than a webpage.
Please no. Leave it to the phones, I don’t want to answer stupid “would you like this app to …” questions to see an image gallery, open a text file or click on an url shortcut. I have trust in my apps, in the same way I trust my guests to not dig in my closets, and it’s not really a huge deal if they do. I don’t want to turn my house into a set of prison cells and guarded corridors, even if I’d have all the keys. If I don’t like you or heard something compromising, you’re simply not welcome, enforced by the only lock on my door.
Please no. Leave it to the phones, I don’t want to answer stupid “would you like this app to …” questions to see an image gallery, open a text file or click on an url shortcut. I have trust in my apps, in the same way I trust my guests to not dig in my closets, and it’s not really a huge deal if they do. I don’t want to turn my house into a set of prison cells and guarded corridors, even if I’d have all the keys. If I don’t like you or heard something compromising, you’re simply not welcome, enforced by the only lock on my door.
You can sandbox apps without stupid UI. Have a look at Qubes OS.
It is technical but I am technical myself. When I have to install some shady app or some fs monstrosity like msvs/mssql, I just clone a generic vbox instance and delete it afterwards. There is no need for a special OS to do that (which may have native drivers issues, will it even run gta?)
If my grandma was into computers, I can’t see how qubes os could help her. Downloading and running ransomware in the “finance” isolation or visiting her bank in “recipes” isolation is still possible, because she isn’t techincal, and I’m not her personal system administrator who sets up firewalls and email filtering or provides 24/7 support. I’m not arguing for everyone (obviously regular people needed phone/tablet security), I’m just pointing out that it always comes with strings attached – either hardware or freedom related, which is my personal concern.
If my grandma was into computers, I can’t see how qubes os could help her. Downloading and running ransomware in the “finance” isolation or visiting her bank in “recipes” isolation is still possible, because she isn’t techincal, and I’m not her personal system administrator who sets up firewalls and email filtering or provides 24/7 support. I’m not arguing for everyone (obviously regular people needed phone/tablet security), I’m just pointing out that it always comes with strings attached – either hardware or freedom related, which is my personal concern.
> which may have native drivers issues, will it even run gta?
Qubes uses Linux drivers. However, games will not work unless you do GPU passthrough (with second GPU).
> When I have to install some shady app
Good UI allows you to move the line of what "shady" means. You can significantly decrease your trust in apps with a reasonable effort. For instance, I run Zoom in a VM, it feels great.
> If my grandma was into computers, I can’t see how qubes os could help her.
You indeed have to spend some effort to use Qubes OS. However if your grandma cares about security/privacy, she could perhaps use basic Qubes functionality like having two VMs, one for everything trusted and the other for everything untrusted. VMs on Qubes look like normal windows, so it's not that complicated to work with. You have to separate your workflows though.
> I just clone a generic vbox instance and delete it afterwards
Hardware VT-d virtualization is much more secure. Also the GUI is more user-friendly.
Qubes uses Linux drivers. However, games will not work unless you do GPU passthrough (with second GPU).
> When I have to install some shady app
Good UI allows you to move the line of what "shady" means. You can significantly decrease your trust in apps with a reasonable effort. For instance, I run Zoom in a VM, it feels great.
> If my grandma was into computers, I can’t see how qubes os could help her.
You indeed have to spend some effort to use Qubes OS. However if your grandma cares about security/privacy, she could perhaps use basic Qubes functionality like having two VMs, one for everything trusted and the other for everything untrusted. VMs on Qubes look like normal windows, so it's not that complicated to work with. You have to separate your workflows though.
> I just clone a generic vbox instance and delete it afterwards
Hardware VT-d virtualization is much more secure. Also the GUI is more user-friendly.
> Hardware VT-d virtualization is much more secure. Also the GUI is more user-friendly.
What's the security difference?
AFAIK all modern VM hosts use everything available, Intel VT-x, EPT, VT-d, VT-c, AMD RVI, whatever. Virtual Box ain't an exception.
What's the security difference?
AFAIK all modern VM hosts use everything available, Intel VT-x, EPT, VT-d, VT-c, AMD RVI, whatever. Virtual Box ain't an exception.
1. It prevents DMA attacks allowing PCI devices to read, write the memory.
https://www.qubes-os.org/faq/#why-is-vt-dadm-viamd-iommu-imp...
2. Meltdown, the most reliable attack of the three discussed, cannot be exploited _from_ a fully-virtualized (i.e. HVM or PVH) VM.
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qs...
3. It serves as an additional virtualization layer on top of Xen supervisor, decreasing the attack surface and making some serious bugs not harmful.
https://www.qubes-os.org/news/2017/07/31/qubes-40-rc1/#fully...
https://www.qubes-os.org/faq/#why-is-vt-dadm-viamd-iommu-imp...
2. Meltdown, the most reliable attack of the three discussed, cannot be exploited _from_ a fully-virtualized (i.e. HVM or PVH) VM.
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qs...
3. It serves as an additional virtualization layer on top of Xen supervisor, decreasing the attack surface and making some serious bugs not harmful.
https://www.qubes-os.org/news/2017/07/31/qubes-40-rc1/#fully...
While I agree with this article, it's interesting to note that by far the most spying occurs on mobile phones, which are very sandboxed. Maybe because that's where the money is.
To be fair, we don't have the other kinds of exploits on phones, like ransomware, so it does show that sandboxing mitigates many risks.
To be fair, we don't have the other kinds of exploits on phones, like ransomware, so it does show that sandboxing mitigates many risks.
the sandboxing makes it hard to modify applications to remove spyware. the app design for websites keeps you from using adblock to block them,
The entire thing is a captive market that desktops didn't worry about because only trusted apps get installed so the "download our desktop app" spam popups wasn't as effective as the mobile versions, leaving the shady activity to websites that could be modified with extensions to remove unwanted behavior.
Edit: also, fuck safetynet
The entire thing is a captive market that desktops didn't worry about because only trusted apps get installed so the "download our desktop app" spam popups wasn't as effective as the mobile versions, leaving the shady activity to websites that could be modified with extensions to remove unwanted behavior.
Edit: also, fuck safetynet
The model of security given in the article is a horrible way of implementing the principle of least privilege.
A better way is set a reasonable set of resources aside for the exclusive use of a given program (for storing state, etc.) and then using system dialog boxes to pick/choose other files/resources to work with. If done correctly, the user wouldn't even notice the difference in most cases.
A technical user could set up better defaults.
You're not going to get there using sandboxes on top of Linux, Windows, etc. Security has to be enforced in the OS kernel. I suspect eventually we'll end up using something like Fuchsia, Genode, Hurd, etc.
[Edit] It seems to me the composability aspect of unix needs to be re-interpreted in a way that allows composing of resources (capabilities) to be passed to a program. One could take a given resource and make it read-only for example. Email access that can only read a certain folder, or contacts, but never send, copy, etc. would be handy to be able to express. You could then pass that limited, specifically tailored set of things to a process with no other access to anything.
A better way is set a reasonable set of resources aside for the exclusive use of a given program (for storing state, etc.) and then using system dialog boxes to pick/choose other files/resources to work with. If done correctly, the user wouldn't even notice the difference in most cases.
A technical user could set up better defaults.
You're not going to get there using sandboxes on top of Linux, Windows, etc. Security has to be enforced in the OS kernel. I suspect eventually we'll end up using something like Fuchsia, Genode, Hurd, etc.
[Edit] It seems to me the composability aspect of unix needs to be re-interpreted in a way that allows composing of resources (capabilities) to be passed to a program. One could take a given resource and make it read-only for example. Email access that can only read a certain folder, or contacts, but never send, copy, etc. would be handy to be able to express. You could then pass that limited, specifically tailored set of things to a process with no other access to anything.
We had this since... 2000? But better.
Sandboxing is not the best solution. Too slow and too high level. The solution is Access Control (Rules) in the kernel, hooked into every kernel function call.
Example: The kernel function for 'read some bytes from a file' is called by a user space process. The kernel function checks the access control rules first. Is this action whitelisted? Is the process x, started from user y, allowed to do this at a weekend, after the user did that other action? And so on.
That idea's most extensive implementation is RSBAC https://en.m.wikipedia.org/wiki/RSBAC — the other and better known one is SELinux.
You should never try to ask a end user to set these rules. For RSBAC a specialist must configure the basic rule set for your system. Later a trained administrator can tweak the running machine if some special rules for a new software are needed.
Sandboxing is not the best solution. Too slow and too high level. The solution is Access Control (Rules) in the kernel, hooked into every kernel function call.
Example: The kernel function for 'read some bytes from a file' is called by a user space process. The kernel function checks the access control rules first. Is this action whitelisted? Is the process x, started from user y, allowed to do this at a weekend, after the user did that other action? And so on.
That idea's most extensive implementation is RSBAC https://en.m.wikipedia.org/wiki/RSBAC — the other and better known one is SELinux.
You should never try to ask a end user to set these rules. For RSBAC a specialist must configure the basic rule set for your system. Later a trained administrator can tweak the running machine if some special rules for a new software are needed.
It's funny to see this on HN now - I think this is a real issue, particularly as a dev with all the random libraries we download and run (cough npm cough), and I just got finished with protecting myself against this issue.
What I did: my MacBook Pro now has two separate MacOS installations, each on a separate partition with full disk encryption/filevault enabled, and separate passwords/encryption keys. One is strictly 'personal' - it has the bare minimum of software installed, and everything remotely sensitive (email, banking, passwords) happens here. The other is where I code and install whatever I want, and nothing personal touches this OS.
It can be inconvenient during the day, but I also treat my smartphone as a secure device (iOS) so there's that.
What I did: my MacBook Pro now has two separate MacOS installations, each on a separate partition with full disk encryption/filevault enabled, and separate passwords/encryption keys. One is strictly 'personal' - it has the bare minimum of software installed, and everything remotely sensitive (email, banking, passwords) happens here. The other is where I code and install whatever I want, and nothing personal touches this OS.
It can be inconvenient during the day, but I also treat my smartphone as a secure device (iOS) so there's that.
I find it hilarious the article is written by a Chrome developer.
Chrome is not a Windows store app. It could have been (MS edge was for years) but it's not. Store apps are substantially more secure than Win32 apps, at the cost of smaller API surface and less permissions.
Chrome is not a Windows store app. It could have been (MS edge was for years) but it's not. Store apps are substantially more secure than Win32 apps, at the cost of smaller API surface and less permissions.
The article is about sand boxing APIs in the OS. He does mention that app stores are not a solution and gives sound reasons.
> The article is about sand boxing APIs in the OS
At the time of writing, all third-party Windows store apps were running inside of such an API sandbox. Windows did not use virtual machines for that, but the sandbox is quite good nevertheless. AFAIK they used CreateRestrictedToken API to implement that.
> He does mention that app stores are not a solution and gives sound reasons.
Despite one can now technically package any Win32 app into the store now, this does not mean there’s no API sandbox anymore. Developers can still code against UWP APIs only, and the OS will use a sandbox for such apps.
At the time of writing, all third-party Windows store apps were running inside of such an API sandbox. Windows did not use virtual machines for that, but the sandbox is quite good nevertheless. AFAIK they used CreateRestrictedToken API to implement that.
> He does mention that app stores are not a solution and gives sound reasons.
Despite one can now technically package any Win32 app into the store now, this does not mean there’s no API sandbox anymore. Developers can still code against UWP APIs only, and the OS will use a sandbox for such apps.
It seems to me that a secure OS would be an OS I wouldn't care to use. It would be so locked down that I couldn't really tinker with it.
The devices and services I use are sufficient for my threat model.
All I can do is mitigate the risks that I'm worried about the most. Those threats aren't such that I'd need to not use those devices/services. If they were I would simply not use them.
All I can do is mitigate the risks that I'm worried about the most. Those threats aren't such that I'd need to not use those devices/services. If they were I would simply not use them.
Have a look at Qubes OS. It's a joy to use for me.
It's a great project and their articles and blogposts are always make for a good read.
I'm probably missing something but W10 has for some time had a Privacy dashboard built in that explicitly lists and gets your permission to grant access for apps to things like Camera, Microphone, Location, Account info, Notifications, Contacts, Calendar, Phone calls, Messaging, Tasks, etc etc... in the same way my phone OS does. I'm sure macOS does the same thing too. Is this not good enough or is there a lack of trust in this protection?
This reads like fearmongering paranoia-propaganda for driving people towards the authoritarian centralised walled gardens...
The problem is once you give an app perission then you never know when it's turning on the mic or the camera.
The microphone and camera are unplugged when not in use.
"secure"? No thanks, I'd rather sacrifice some security and keep my freedom. We're already losing the war against general-purpose computing.
The problem is once you give an app perission then you never know when it's turning on the mic or the camera.
The microphone and camera are unplugged when not in use.
"secure"? No thanks, I'd rather sacrifice some security and keep my freedom. We're already losing the war against general-purpose computing.
What about snaps on Ubuntu? https://www.howtogeek.com/670084/what-you-need-to-know-about...
But everyone hates snaps.
Huge files (made worse by an insistence on keeping two versions of everything around). Slow to start even a simple calculator. Fills the mount list with spam. All to deliver the "feature" that Discord can't share a file from ~/.minecraft/screenshots/whatever.png and ffmpeg can't access /dev/video0
Users prefer dpkg so clearly that Canonical had to make a fake dpkg file for Chromium that installs it using snap.
Huge files (made worse by an insistence on keeping two versions of everything around). Slow to start even a simple calculator. Fills the mount list with spam. All to deliver the "feature" that Discord can't share a file from ~/.minecraft/screenshots/whatever.png and ffmpeg can't access /dev/video0
Users prefer dpkg so clearly that Canonical had to make a fake dpkg file for Chromium that installs it using snap.
I love Snaps:
- When there is new security fix, like new version of Node.js, I release new version of Wekan https://wekan.github.io and all those about 9000 servers worldwide are updated automatically soon and safe from that vulnerability. Wekan migrations upgrade database schema etc automatically.
- When Snap is upgraded, it upgrades very fast, compared to Docker
- Snap does not have layers taking big amount of disk space, like Docker
- Snap sandbox works very well. Snaps with strict confinement (like Wekan) can not access files outside of /var/snap/wekan/common directory.
- Snaps are the reason to select Snap compatible distro https://snapcraft.io/docs/installing-snapd .
Is there any other automatic update system like Snap? AFAIK other update systems require manual steps to update.
- When there is new security fix, like new version of Node.js, I release new version of Wekan https://wekan.github.io and all those about 9000 servers worldwide are updated automatically soon and safe from that vulnerability. Wekan migrations upgrade database schema etc automatically.
- When Snap is upgraded, it upgrades very fast, compared to Docker
- Snap does not have layers taking big amount of disk space, like Docker
- Snap sandbox works very well. Snaps with strict confinement (like Wekan) can not access files outside of /var/snap/wekan/common directory.
- Snaps are the reason to select Snap compatible distro https://snapcraft.io/docs/installing-snapd .
Is there any other automatic update system like Snap? AFAIK other update systems require manual steps to update.
From a user perspective : it does work. I always had issues running Spotify on it if I ran a newer Ubuntu than Spotify built their application for. Now I run the snap and everything just works.
That might just be because you're now running the latest version?
Were you previously running the distro supplied Spotify or from Spotify's own APT repo?
Were you previously running the distro supplied Spotify or from Spotify's own APT repo?
> The microphone and camera are unplugged when not in use.
I guess you don't use any laptops than.
> I'd rather sacrifice some security and keep my freedom. We're already losing the war against general-purpose computing.
That's a false dichotomy. As a user you can give all the permissions you want to a sandboxed app you want to use. The only one losing freedom is the potential malware writer.
If you are true to this sentiment, I guess you run everything under the root/admin account of the computer, because that gives you maximum freedom, right? A non-root user is a sandboxed user.
I guess you don't use any laptops than.
> I'd rather sacrifice some security and keep my freedom. We're already losing the war against general-purpose computing.
That's a false dichotomy. As a user you can give all the permissions you want to a sandboxed app you want to use. The only one losing freedom is the potential malware writer.
If you are true to this sentiment, I guess you run everything under the root/admin account of the computer, because that gives you maximum freedom, right? A non-root user is a sandboxed user.
I don't have to run everything as root. I just need the option to easily run something as root when I choose to. An option that is denied to me on those walled garden phone OSes.
Like many here, I’m sure, I would love to be able to physically disable my camera and microphone somehow but do not have that option.
That’s cool! I could envision buying something like that someday, but in the meantime and for the past 10 years I was hoping to do it with a MacBook Pro and an iPhone.
> The microphone and camera are unplugged when not in use.
Seems really inconvenient to have to physical unplug things when you're not using them. And in laptops and other integrated devices you can't unplug them.
Seems really inconvenient to have to physical unplug things when you're not using them. And in laptops and other integrated devices you can't unplug them.
> And in laptops and other integrated devices you can't unplug them.
This is why Purism makes laptops and phones with kill switches: https://puri.sm/security/
This is why Purism makes laptops and phones with kill switches: https://puri.sm/security/
but you can always put small physical switches anywhere in the device to turn them off by hardware.
[deleted]
Same here. When I don't want random apps sniffing my files, I just unplug my HDD!
Such OS exists since 2012. Has been my daily driver for years, can't recommend it enough: https://qubes-os.org
I feel like Linux has the building blocks, it's the configuration necessary to take full advantage of them that is overwhelming.
When I used to use Windows there was also sandboxie which whilst probably wasn't perfectly secure was a good first point of call if you wanted to take a bit more care without firing up a whole VM - was especially interesting to see where apps would dump files as part of their installation process since they were operating in a clean directory tree
When I used to use Windows there was also sandboxie which whilst probably wasn't perfectly secure was a good first point of call if you wanted to take a bit more care without firing up a whole VM - was especially interesting to see where apps would dump files as part of their installation process since they were operating in a clean directory tree
[deleted]
Easy, when security stops being optional.
Until then, don't complain if random app gets to encrypt and send $HOME to other side of the planet.
Until then, don't complain if random app gets to encrypt and send $HOME to other side of the planet.
You want https://www.qubes-os.org/
When will we get secure cars...
When will we get secure nuclear power plants...
When will we get secure vaccines...
When will we get secure cars...
When will we get secure planets (without fires,floods, earthquakes, etc.)...
Bla bla bla.
When will we get secure nuclear power plants...
When will we get secure vaccines...
When will we get secure cars...
When will we get secure planets (without fires,floods, earthquakes, etc.)...
Bla bla bla.
[deleted]
Never.
I wonder if OP is also against all sort of farmer's food. After all, how can you know if the farmer didn't inject the apples he sold you with cyanide (or mini cameras) ? Or maybe the tree grew on a radioactive rock and the apples will give you cancer ten years after ? The only way would be to entirely control food production from the very start in an industrialised and verified way, no ?
> The only way would be to entirely control food production from the very start in an industrialised and verified way, no ?
I'm not sure whether you are aware that the way you described it, it actually is in reality. So the sarcastic approach is a little misplaced here.
There are literally institutions that random select tests of food products to ensure their quality. If it's off or outside law regulated guidelines, the manufacturer loses the license to sell it.
In the European Union all recipes have to be approved before they are allowed to go on the market. There are even a few prototype cities (e.g. Hassloch in Germany) to test products before they roll out officially. So it literally is an end-to-end, industrialized, testchain.
The difference here is: It's not the manufacturer that controls itself. It's an independent agency or research institute.
And that is literally what OP was complaining about.
I'm not sure whether you are aware that the way you described it, it actually is in reality. So the sarcastic approach is a little misplaced here.
There are literally institutions that random select tests of food products to ensure their quality. If it's off or outside law regulated guidelines, the manufacturer loses the license to sell it.
In the European Union all recipes have to be approved before they are allowed to go on the market. There are even a few prototype cities (e.g. Hassloch in Germany) to test products before they roll out officially. So it literally is an end-to-end, industrialized, testchain.
The difference here is: It's not the manufacturer that controls itself. It's an independent agency or research institute.
And that is literally what OP was complaining about.
> I'm not sure whether you are aware that the way you described it, it actually is in reality.
Note that I'm not talking about industrialised production, but about people selling their fruits at the side of a road, who may not even be farmers but just have a large garden ; we had only 3/4 fruit trees when growing up but it'd often make enough to give kilograms of apricots & such can be given away or sold for a few euros at the local fair. I don't remember anyone getting UE approval to be able to do that, any more than a kid needs UE approval to sell lemonade.
Note that I'm not talking about industrialised production, but about people selling their fruits at the side of a road, who may not even be farmers but just have a large garden ; we had only 3/4 fruit trees when growing up but it'd often make enough to give kilograms of apricots & such can be given away or sold for a few euros at the local fair. I don't remember anyone getting UE approval to be able to do that, any more than a kid needs UE approval to sell lemonade.
I think Apple (Computers) can't be compared with organic food because Apple's business and operations model implies that everything is protected intellectually with patents.
Protecting your manufacturing process via patents implies that "people at the side of the road" don't know how to make it. Otherwise the patent would be nullified.
To stay with the metaphor I think we'd have to classify Apple (Computers) as a processed food manufacturer and not the same was as organic food, and also not as something that other people can easily grow themselves in their backyard.
That would be probably something like a USB cable or maybe a touchpad or something, but even that far outreaches the knowledge of the general population that are not specialized in the area. Planting a seed and taking care of a plant to grow it, is pretty much doable by a child in comparison.
Protecting your manufacturing process via patents implies that "people at the side of the road" don't know how to make it. Otherwise the patent would be nullified.
To stay with the metaphor I think we'd have to classify Apple (Computers) as a processed food manufacturer and not the same was as organic food, and also not as something that other people can easily grow themselves in their backyard.
That would be probably something like a USB cable or maybe a touchpad or something, but even that far outreaches the knowledge of the general population that are not specialized in the area. Planting a seed and taking care of a plant to grow it, is pretty much doable by a child in comparison.
For an example see this article, worth reading:
https://www.grubstreet.com/2020/12/2020-bucatini-shortage-in...
The sequel:
https://www.grubstreet.com/2021/02/de-cecco-bucatini-shortag...
https://www.grubstreet.com/2020/12/2020-bucatini-shortage-in...
The sequel:
https://www.grubstreet.com/2021/02/de-cecco-bucatini-shortag...
I would not recommend this article if you can't handle a load of New York pasta nerdiness before getting to the SAUCE, capisci?
The secure desktop "OS" exists. It's called a browser.
We have reached the point where most people can get by purely using browser based software that is secure because browsers use good sandboxes.
We have reached the point where most people can get by purely using browser based software that is secure because browsers use good sandboxes.
Calling a browser "secure" is quite the stretch...