There is always at least a small risk when installing a package for a distribution. By its very nature, package installation is an invasive process; some packages require the ability to make radical changes to the system – changes that users surely would not want other packages to take advantage of. Packages that are made available by distributions are vetted for problems of this sort, though, of course, mistakes can be made. Third-party packages are an even bigger potential problem because they lack this vetting, as was discussed in early October on the debian-devel mailing list. Solutions in this area are not particularly easy, however.
Both Desktop Linux and Windows are horrible in that regard, in the sense that they train the user to give sudo/admin permission to installers or packages by default.
Desktop Linux is even worse than Windows in the sense that both dpkg and rpm require sudo for themselves…
Android is good in this regard, because it bans packages from even asking for sudo access. This way, app vendors can’t use the well-known trick of “give our package/installer sudo access or no soup for you”. Which is why you can uninstall and install applications on Android without the OS suffering from any “rot” effect.
Edited 2018-11-17 09:35 UTC
msiexec requires elevated execution as well in windows, if the MSI package is installed for all users or machine. However, it is possible for some MSI packages to be installed for a single user, in an user context without administrative privileges.
On the other hand, you may use AppImage files on desktop Linux without sudo, or even without installing anything.
Sorry but, at least for me, having a trusted central place from where everything I need that touches the system main components gets updated from is a huge advantage of linux systems on the server side hands down.
On workstations, for cases where people needs more up-to-date versions, the thing is shaping well with flatpak, snap and appimage, all of them equivalent or superior to current situation on windows. You don’t need root access for them to be installed on your own user directories.
What people have been discussing is how to have a more fine grained control over what needs to touch the main system components, out of concern that someone can “infect” the distribution repositories, or to prevent accidental mistakes that could compromise the system files, or even cutting the possibility of “tainted” sources files from getting compiled and deployed without a double check. I’m sure it is also a matter of concern to Microsoft, for their own packages and for packages we need to install in our systems to complement what MS does not provide.
In theory, Linux installers are allowed free reign to wreck havok and Android requires users to approve permissions at install.
In practice, the repositories of every Linux distro I’ve used can be used without any worry; while the vast majority of applications found in Google Play request excessive permissions specifically to do something undesirable, usually involving tracking your behavior and sending to various data aggregators to be sold on.
That comes at a price though, in the sense that every piece of software that goes into the repos has to be manually scrutinized first. You can’t have IndieSoft pushing Adventure X in the repos and having it available to users the next day, or have IndieSoft push proprietary software to the repos (that can’t be scrutinized manually), or even having the latest versions of apps immediately available. IndieSoft would have to put out a Deb and RPM and the user will have to give it sudo.
Android was made to be open to app developers (open source and proprietary developers) from day 1, and encourage users to try out apps, and the permissions system is necessary to achieve these goals without ending up like Windows XP.
Edited 2018-11-18 12:29 UTC
I’d like to point out that while most mainstream Linux distros do require root/sudo access to install/update packages, that is not true of all flavours of Linux and package formats.
If you use Nix you can allow any specific users to run the package manager. Likewise, portable packages like AppImages so not require admin access to download and run.
So it’s entirely possible to set up your Linux system in a way which side steps the root/sudo requirement.
I appreciate the effort to solve the packaging mess of Desktop Linux, but I will believe it when I see it becoming the default. As of now, most apps are still available only via the repos, or at least old versions of them for most distros.
Sudo or not – both sux. Maybe on server system it`s important, but at desktop? So what, if program does not get access to root, if it still can touch my photos and files, or run little spam-server… I should give any app aproves for any part of userspace. Maybe I`ll let it touch home folder, or give it only one app folder to use. Maybe I don`t let it to get webcam or network? At the moment any program (without tweaking) can touch every thing that I can. Why would Skype be allowed to read my home folder without my premission?
That’s a result of the idea that an app should “inherit” all the permissions the user running it has. Blame the designers of Unix for having that idea. There were attempts to patch the problem but none of it actually enforced.
Again, Android has solved this problem.
Edited 2018-11-19 11:51 UTC
Hardly. Android simply trains the user for a different kind of click-through dialog. Agree to these permissions or your package doesn’t get installed, and very few users actually read what is going to happen. Root access is hardly the main problem average users face, rather it’s data stealing and other forms of nasty that don’t need root for anything whatever.
darknexus,
I’m a big supporter of sandboxing, and like kurkosdr I think android has done a lot to improve sandboxing over desktop operating systems (be it linux or windows). However I have a lot of issues with android’s all or nothing implementation. This approach is extremely flawed because it denies informed users the ability to grant only those permissions they want to grant as needed rather than being forced grant all the permissions when installing an application. This security flaw in android bugs me every time it comes up when I’m installing applications. Obviously google knows it limits owner control, but I suspect they haven’t fixed it because google really doesn’t want users having control over permissions for google’s own apps.
Newest versions of Android have this exact thing. The app asks for zero permissions at install time (and receives zeo permissions at install time of course), and you can grant permissions as you run the app. The requirement to ask for zero permissions at install time is enforced for all apps targeting a certain API version and above (which means an app has to play ball if the programmer wants it to have access to the cool new APIs the Google people introduce with every Android version). And you can revoke permissions after you grant them of course.
Old apps still use the old all-or-nothing install-time permissions (of course) but they become less and less by the year (as of now it’s mostly old unmaintained games).
Of course, some app developers just put a loop during app startup that keeps asking for all permissions to be granted and doesn’t allow the app to run until they are granted, but some apps only ask for a permission once and then work around the lack of any permissions (for example, the Google keyboard, if you don’t give it access to your contacts, it won’t use your contacts’ names in the autocorrect).
Basically, what I just described is the most an OS can enforce because some apps may really need some permission to work (any permission) so you can’t force an app to workaround all missing permissions (not to mention the challenges of implementing such enforcement).
Edited 2018-11-19 18:33 UTC
kurkosdr,
What? No…please don’t tell me google screwed this up again! They have got to fix this for good for all applications even if it means feeding fake data to applications that don’t behave!
Edited 2018-11-19 19:19 UTC
That would breach the API contract and would result in weird app malfunctions. This is the real world, you can’t just randomly break stuff like the Shuttleman (of Canonical) did with PulseAudio back in the day. Anyway, any apps not playing ball would have to become more and more stuck in the past, as any Android API above Marshmallow cannot be used, and most importantly the Play Store will not accept any submissions targeting anything older than Android Oreo (note: the Android Support Library means your Nougat phone will run these Oreo apps btw). Not getting into the Play Store is a hefty price to pay if you want all or nothing permissions.
PS: You can revoke permissions for old apps I think post-installation. Haven’t tested what happens and can’t find any old apps beyond old unmaintained by purchased games the developer can’t pull from the Play Store (Asphalt 6 and Asphalt 7 come to mind).
Edited 2018-11-19 20:01 UTC
kurkosdr,
Most of the IOT apps I use to connect to physical devices around the house are using older APIs. See ‘radio thermostat’ for an example. It was last updated in august and still uses kitkat level 19 API. I’m glad I can still get those apps since I still use them. Google clearly isn’t blocking those APIs, at least not for established apps.
I’ll grant you the new app permission model should be much better going forwards, but a proper sandbox needs to work unconditionally. If there’s a hole that lets private data slip through, whether it’s a legacy API or not, then I consider it a bug.
Edit: I’ve disabled the permissions for a few legacy apps now, without noticing any issues. So maybe it works? I’d like to confirm that the permissions are actually disabled and not just silently ignored, but so far so good.
Edited 2018-11-20 08:18 UTC
Who knows? Haven’t tried declining permissions for legacy apps, you are on your own on this one.
Edited 2018-11-20 13:02 UTC
It’s as if Google is subsidizing the development of the entire OS just so they can put their online services (and the data collection that comes with it) on the majority of smartphones on the market
kurkosdr,
Why do the various google play services (among other things) need my camera, mic, sms, and contacts though? I know OS vendors can get away with a lot, but it’s still creepy IMHO.
“Services” apps from Google (the ones with the piece-of-puzzle icon) act as compatibility layers for other apps (essentially they translate API calls for new APIs to older API calls that your device can understand) to reduce the amount of statically linked code needed, and they also provide the GMS APIs, for example the Google location APIs that every geolocation-related app uses (the AOSP location APIs are junk and require manually combining GPS, cellular and WiFi location to one set of coordinates while Google location does that automatically, so nobody uses the AOSP ones). Android Pay APIs is another example.
So yeah, it’s expected the “Services” apps have access to many permissions because they are part of the device’s API. Haven’t look what the “normal” Google apps ask for, you ‘ll have to look yourself.
Edited 2018-11-21 23:14 UTC
kurkosdr,
It’s unclear / non-obvious to me who has access to what when “google play services” is given access to things like location/camera/microphone/contacts/etc?
I know on my earlier version of android I had to click a popup to reject google’s tracking every time I started the GPS, but it’s not clear if google even respected that choice:
https://www.independent.co.uk/life-style/gadgets-and-tech/news/googl…
Google cares about third-party apps not doing things behind the user’s back with the microphone and location, if you want to have total oversight, you are on your own.
But Play Services can’t be used to bypass the location permission for example if that’s what you are asking.
Edited 2018-11-22 13:06 UTC
BTW you can try installing Hangouts and placing a call. If your Android 7 phone doesn’t give you the choice to allow or deny microphone access, you were sold a phone that doesn’t meet the Android Compatibility Definition.
All recently updated apps do this on phones running Marshmallow or higher, because if they want to get into the Play Store they have to target Oreo (soon Pie). Google crafted this rule specifically for Facebook, who were targeting old API versions in their recently updated apps on purpose in order to avoid the new power management rules that come with new APIs.
Edited 2018-11-19 20:27 UTC
kurkosdr,
I don’t use facebook, but many apps I use are still targeting older APIs and were recently downloaded from google’s store, so something is incorrect with your statement or assumptions here. They might have applied those rules to facebook, but it’s certainly not the case across the board.
Edited 2018-11-20 08:31 UTC
Download doesn’t matter, it matters when the apps were updated.
From what I read, for updated apps, the “no-more-earlier-target-than-Oreo” date is 1 Nov 2018, so you have to wait for apps to be updated I guess…
https://android.gadgethacks.com/news/google-forcing-apps-target-oreo…
Edited 2018-11-20 12:18 UTC
kurkosdr,
Well it’s kind of important to have confidence in the sandbox settings. As long as those settings are indeed being respected in all scenarios even at older app levels, that’s all I ask for.
It sounds like people are still having the same arguments as they were 15-20 years ago. Why not try a different direction?
From what I understand Solus’s eopkg system is fully declarative (ie. no scripts), and is designed to be 100% transactional with rollback. I’ve used the rollback part, it’s pretty slick. More info here: https://getsol.us/2018/02/15/exploring-solus-architecture/
But I think the best technique leverages union-fs, which I believe is Haiku does package management. No copying files, no running scripts, the “app” is just a read-only disk image that is unioned on top of the root fs. Delete the disk image, uninstall the app.
I think the Haiku solution is very nice, but I would like to point out that it makes it easier for bad software to run on your system, not more difficult.
A rogue package could override vital system functionality easily.
The upside is it’s really easy to get rid of rogue packages without affecting anything else.
For me, this issue is about the point of trust.
When I installed the operating system and allowed it access to my files, I took a decision to trust the engineers and developers of the operating system. I realise that when I apt or yum update or install and put in my admin or sudo password I’m giving the software an immense amount of power. However, this is not a decision I’m making on update or install of any software in the repositories. I already made a decision when I installed the OS all I’m doing is confirming the previous decision, I trust the developers and engineers involved in making the OS; I, therefore, trust what they allow in the repository they control – I accept that they might make a mistake, but I believe they are acting in goodwill.
This is not the same as giving admin privileges willy nilly this is a simply confirming a decision I took at install time. There are consequences – I know that what’s in the repository may not be the latest and greatest version of the software, I have to accept this if I want to use the os developers repository. I occasionally add other repositories because I want newer software or software that isn’t available in the main repositories, if I do this I am also making the decision that I trust the developers that control this repository, and it isn’t something that I do lightly.
I’m not sure what I think of the AUR that arch has available, I’m not an Arch user, and I can see advantages but also see that this moves the point of trust to the developers of the individual items of software, which I’m a little uncomfortable with. I like the central repositories I’m happy to make the compromises it entails to use them.
Snaps and Flatpaks for me don’t substantially solve the problem; I would still want to install from the os developers repository. On my desktop, the software having access to my system is less significant than it having access to my files. I can reinstall the os and software in an hour, however, my files are much more precious to me.
Edited 2018-11-19 05:12 UTC
Yup, it’s this mentality of central control by the OS vendor that killed Desktop Linux in the marketplace (along with bad power management and poor GPU drivers of course). For most people, the OS is a layer to run their apps on (and by “their” I mean any app they want to, for better or worse), they don’t want the OS vendor having a tight grip over the apps, because the OS vendor will abuse it. People want the OS vendor to certify software with a signature system so they can make a more informed decision and scan the app store for malware, but not more…
People are not as dumb as the graybeards that make Desktop Linux thing they are. They know when a system restricts their choices.
Edited 2018-11-19 12:00 UTC
Mmm this seems unlikely to me.
If I consider phone OS they seem to be very successful, even though they have repositories such as Google play and sometimes very restrictive walled gardens (Apple). I grant you these are not desktop computers. I personally intensely dislike installing software on windows. which too often involves going to a site that desperately wishes me to install some horrific pseudo utility whist hiding the link for the software I might want. Maybe I’m odd and others enjoy this process.
Desktop Linux doesn’t make it difficult to install outside of the central repository. I can usually quite easily install a lone package file and have the system install any dependencies or I can add a third party repository. In many systems this is simple and doesn’t require extensive use of the command line. We also have well supported third party utilities such as Steam. Personally I generally choose not to do this I simply don’t mind if my software is not the latest as long as its patched and safe.
I think there are reasons we don’t have greater adoption of desktop Linux and some of these reasons are software related, but I don’t think you’ve identified the most significant reasons.
The developer can push stuff to the Play Store and App Store directly and have it available to users in a day. Big difference.