Do you trust this application? | Hacker News Reader

Do you trust this application?

blogs.gnome.org

57 pointsmkesper17 comments

Is the author saying we need mobile-style app permissions on the linux desktop? (I know there's apparmor but I don't understand it). That would be awesome.

Throw phone-home & disk access restrictions into the mix and I'm even happier.

I know there are sandboxing tools for linux desktop -- the community needs to identify one that's easy to use and start using it. Let's recruit closed-source OS users to linux by dangling easy-to-use privacy.

Did you read the article? He particularly calls out applications which use HTTP and/or are vulnerable to MITM attacks. They're not really "sexy" bugs to fix and many older open source projects are languishing, since it's much more fun to create new software than maintain old software written by someone else.

Sandboxing doesn't fix apps not validating SSL certificates?

correct, but it limits the data they can exfiltrate. I can live more easily with my weather app downloading its upgrade patch over HTTP if there's a sandbox limiting what that hostile update will do when it lands.

The Linux kernel has had a lot of holes in the namespace stuff used for containers, I doubt that there will not be more. Not to mention all the local root exploits, seLinux-bypass, information leaks and so on. If you're relying on Linux features for security without at least using the grsec patches, you probably already lost.

A piece of this issue is distributions, and it somewhat might be better for rolling release distros.

Also, at least for his examples, these are fairly low popularity products, as much as I like Gnome[0] and its ecosystem, it's the truth. Shotwell? He said it himself, no one develops it anymore. Epiphany (vs. Firefox vs. Chrome) Gnome Music, Weather? It doesn't help that the userbase is small and thus, the developer base is even smaller.

Would we see the same apathy with Firefox, VLC, mplayer, not to mention bash or openssl? Probably not (as we have seen especially with the last two).

[0] Not being sarcastic, imao, Gnome 3 blows Unity,Gnome 2,KDE, and even OS X out of the water in my book, which makes me sad it isn't as popular as Unity.

Most of the bugs he refers to aren't even fixed in git, so yeah, no. The one that is fixed didn't get a CVE so it isn't surprising none of the distro security teams heard about it.

I agree, the fact that the devs aren't even fixing it in the first place is a problem, although as I said, these are unpopular apps with few devs in the first place.

Debian has non-maintainer-uploads in case upstream refuses to fix issues or simply has vanished, and so has Ubuntu.

No idea how other distros solve this issue though. And on Windows with its lack of any package management or update facilities other than whatever homegrown stuff the vendor ships (which leads to dozens of updater processes eating up RAM) the situation is even worse.

Author makes a good point reminding us that free software does not automatically mean secure.

But it's worth pointing out that at least with free software, we are able to assess just how (in)secure an application is. So we can find out which applications to use or avoid if we are interested in security. The same cannot be said for proprietary applications.

> we are able to assess just how (in)secure an application is

Realistically, most people aren't going to do this. A more pragmatic solution is to use a minimal system, where for every task, you always use the smallest application that will perform it in an adequate manner. With proprietary software, you seldom get the ability to set up such a minimal system.

In particular, this means that I will never use a desktop environment, because there is no task for which a desktop environment is the smallest, simplest possible solution.

Depends how you define minimal, functionality or code size and do we count libraries since once you pull in GTK, Qt or something on the JVM you are depending on millions of lines of code anyway.

All else being equal or irrelevant, I prefer the application with the fewest and smallest dependencies, as well as the least amount of features I won't use. For example, the only thing I want in a music player is that it plays music. I don't need to connect to online services to synchronize my playlists, discover new artists, or whatever else “music players” do these days. Thus my preference for moc instead of, say, Amarok.

Source code unavailability does not seem to stop security researchers from finding security issues in proprietary software. The advantage of free software here is of course that more people can read source code than can do security analysis of compiled software.

The author points out the biggest issue I have with open source, there is no owner so their is no reputation so their is no incentive to fix reputation damaging but not functional issues.

Everyone was shocked that like one person was maintaining OpenSSL which everyone depended on, some of the mentioned programs have exactly zero people maintaining them. The package maintainers will do the minimum to get them to compile but that is it. So once you've got a remote execution bug in a commonly shipped but unowned piece of code, you can rootkit all your friends who use it, again and again and again.

Except that incentive doesn't work anyway. For example, last I heard Steam is shipping am ancient, known-vulnerable version of Chromium with sandboxing disabled. The biggest issue with open source security is the same as the biggest issue with closed source security: end users have no idea how secure the software is and can't really do much about it even if they did know.

Well said. I wasn't aware that Steam had continued to ship that Chromium version, what used it?

Reply on news.ycombinator.com