Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

When will we get secure desktop OSes? (2018)

games.greggman.com

Post reply on HN
Print view View original

91–100 of 102 posts

Re: When will we get secure desktop OSes? (2018)

#91

Post by xet7 »

michaelt wrote: post #28
edu-ap wrote: post #16

Earlier quoted context omitted.

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 inst…

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.

Re: When will we get secure desktop OSes? (2018)

#92

Post by _rdvw »

snickerer wrote: post #69
_rdvw wrote: post #30

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://…

Firejail is the solution to the author's concerns. 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

Re: When will we get secure desktop OSes? (2018)

#93

Post by Const-me »

fsflover wrote: post #67
wruza wrote: post #64

Earlier quoted context omitted.

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” is…

> 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 comp…

> 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.

Re: When will we get secure desktop OSes? (2018)

#94

Post by mikewarot »

seanhunter wrote: post #47

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.

Re: When will we get secure desktop OSes? (2018)

#95

Post by foxpurple »

mimi89999 wrote: post #73
foxpurple wrote: post #38

Earlier quoted context omitted.

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…

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.

Re: When will we get secure desktop OSes? (2018)

#96

Post by fsflover »

Const-me wrote: post #93
fsflover wrote: post #67

Earlier quoted context omitted.

> 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 comp…

> 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.

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...

Re: When will we get secure desktop OSes? (2018)

#97

Post by pjmlp »

swiley wrote: post #78
gentleman11 wrote: post #15

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 y…

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.

Re: When will we get secure desktop OSes? (2018)

#98

Post by pjmlp »

helsinkiandrew wrote: post #24

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 usi…

TFTP Net Booting or its modern variant PXE.

Re: When will we get secure desktop OSes? (2018)

#99

Post by Abishek_Muthian »

gentleman11 wrote: post #15

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 y…

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?

Re: When will we get secure desktop OSes? (2018)

#100

Post by swiley »

pjmlp wrote: post #97
swiley wrote: post #78

Earlier quoted context omitted.

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.

>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.

Post reply on HN