Claim that Skype is an unconfined application able to access all one's own personal files and system resources

Question

Situation

I was about to install Skype on a laptop driven by Ubuntu 18.04 LTS Desktop. The software installation helper graciously informs me that Skype

is unconfined. It can access all your personal files and system resources

as per the screenshot below.

Apparently there must be reasons to make a distinction from applications that do not call for this warning.

Reality-checks

Can Skype really scan anything I have in my home directory regardless of the permissions set to files and directories? Does it become like a sort of superuser?
What is the meaning of system resources there? Does it go about functional resources like broadband and memory, or is that an understatement for control on all applications?

Mitigation

How is it possible for an average "power user" to confine such an unconfined application?

Beside the mere answering, pointing out to interesting readings is also appreciated.

Just to put this in context, _any_ software you install is unconfined and has full access to your personal files, unless measures are taken to prevent it, such as it being a strict Snap or by only running it under a different, unprivileged user account. Your browser, word processor, games etc. typically have full access to your user account's files. This is indeed an antiquated security model; mobile devices have a much more isolated model. snap is somewhat of a step in the right direction too. — multithr3at3d, Mar 15 '20 at 19:41
Probably not worth putting as an answer, but Canonical (the company that does much of the development of Ubuntu) have been pushing Snaps quite hard, which they argue are simpler and more secure than the older Debian packaging machinery, which they also still support. These warnings look like they're trying to steer you away from Debian packages, but Debian packages remain widely used and supported. — James_pic, Mar 16 '20 at 13:55
You could also use [firejail](https://firejail.wordpress.com/) to confine Skype. — Benjamin, Mar 16 '20 at 14:19
@James_pic Skype itself provides a Debian package at https://go.skype.com/skypeforlinux-64.deb It would be interesting, for the non-expert at least, to know in which respects it differs from some golden-standard deb package and a Snap packaging... — XavierStuvw, Mar 16 '20 at 14:22
@James_pic According to that screenshot, it came up during an snap installation, its not a .deb installation — Ferrybig, Mar 16 '20 at 16:01
I am wondering whether the good and old technique of chroot-ing could enforce the confinement (at the level of the file system): running the binary under chroot (https://manpages.ubuntu.com/manpages/trusty/man2/chroot.2.html) command, providing a local tree containing a copy of the resources needed by Skype. That could be not simple, even because "Only a privileged process (Linux: one with the CAP_SYS_CHROOT capability) may call chroot()." It is an old and still used practice running processes exposed to attacks (e.g. httpd) under a confined root. — flex, Mar 17 '20 at 20:08
@overmind The OS flame war does not add to the discussion - take it to DMZ — schroeder, Mar 18 '20 at 13:45

score 64 · Answer 1 · answered Mar 15 '20 at 19:30

64

Why am I getting this message?

The idea of snap is to be an "app store for Linux", with much of the same benefits as app stores for other platforms, such as iOS or Android. One of the big advantages is that applications are rather confined, unable to interact with your OS unless the user gives it specific permissions.

In snap, there are several different "confinement" settings, as documented here:

Strict

Used by the majority of snaps. Strictly confined snaps run in complete isolation, up to a minimal access level that’s deemed always safe. Consequently, strictly confined snaps can not access your files, network, processes or any other system resource without requesting specific access via an interface (see below).

Classic

Allows access to your system’s resources in much the same way traditional packages do. To safeguard against abuse, publishing a classic snap requires manual approval, and installation requires the --classic command line argument.

Devmode

A special mode for snap creators and developers. A devmode snap runs as a strictly confined snap with full access to system resources, and produces debug output to identify unspecified interfaces. Installation requires the --devmode command line argument. Devmode snaps cannot be released to the stable channel, do not appear in search results, and do not automatically refresh.

The Skype app is most likely a "Classic" snap, which means you don't get the same benefits as from a strict confinement.

Can Skype really do anything on my system?

Skype can do as much as any other traditional binary can do, such as those installed via apt. It does not generally become "some kind of super user", but it could use sudo or other means to ask to become a privileged process. The easiest way to do that is to simply refuse running as anything but root.

However, Skype cannot magically bypass any file permissions, unless you specifically gave the binary capabilities to do so.

What does it mean by system resources?

Think about apps on your smartphone. Applications have to ask to access your files, your contacts, your microphone, your camera, your location, etc.

Snap in its strict confinement setting does allow applications to access these, but individual applications need to request access to these interfaces. Of course, you as the user can forbid an application from accessing them. Perhaps you don't want an application to access the network because you don't want to use network-enabled features.

What the installer is telling you is that, since Skype is a "classic" snap, you cannot stop Skype from accessing all these resources (network, camera, etc.), at least not in an easy way.

How is it possible to confine such an application?

You can, if you so desire, try to create a strictly confined snap yourself. I assume that this will be a difficult-if-not-impossible task, else Microsoft had done that. Or maybe it's super easy, barely an inconvenience, and Microsoft just didn't care.

You could also create a limited user and configure your system to run the application as this user, then restrict that limited user from accessing resources such as the network, the web cam, etc.

answered Mar 15 '20 at 19:30

28

It should be noted that by the very nature of what Skype is supposed to be doing, it needs access to the network, the web cam, the microphone, the speakers, the address book, and the file system. – Jörg W Mittag Mar 16 '20 at 05:48
4

@JörgWMittag Understandable. But does it need access to the _whole_ file system by such a very nature of its? – XavierStuvw Mar 16 '20 at 07:58
26

Skype includes file sharing, so it needs at least *read access* to every file you might potentially want to share, and it needs *write access* to at least one directory. – Jörg W Mittag Mar 16 '20 at 08:00
2

Minimum requirements are clear, maximum requirements are not. In the user's perspective, is there a way to determine what those boundaries are given a specific application? – XavierStuvw Mar 16 '20 at 08:10
3

@XavierStuvw Without complete knowledge of everything the app does and how it does it, the user has no way to determine the minimum set of permissions required. At best, you could deny all accesses, create a program that tests all combinations, then determine the one which provides you with the best functionality. Such a testing program will be highly valuable, likely worth billions as it essentially automates all usability testing. – iheanyi Mar 16 '20 at 14:19
1

@JörgWMittag If I am not mistaken, Skype on Android has restricted access to the filesystem. and still manages to work just fine. I know Android works differently, but this is just to point out that unrestricted access to the filesystem is not in any way necessary for it to work. – Federico Poloni Mar 16 '20 at 15:01
1

@Pacopaco the idea behind (strictly confined) snaps is to bring that level of compartmentalization to the desktop – mbrig Mar 16 '20 at 18:41
Skype can run in web browser. Something that can run in web browser don't need unlimited access unless it's greedy. – VarunAgw Mar 16 '20 at 23:37
@FedericoPoloni Skype for Android has the largest access possible to the file system, from a regualr user point of view it can access everything. Everything an average user is expected to be willing to share, like documents in shared folders, photos, videos and such. Android file system access is strict and there is no app that can be installed that has full access to the full file system, but for its purposes Skype can access a lot of user-relevant folders. – bracco23 Mar 17 '20 at 14:49
2

@VarunAgw Browsers nowadays expose pretty huge APIs to access local features, and for the kind of access we are talking about (files, hardware, etc), it gives pretty much the same potentiality of a local app, with an added layer of user interaction and abstraction. – bracco23 Mar 17 '20 at 14:51
1

@bracco23 From what I understand, in Skype for Android you can access only files that the user decides to share and "sends" to Skype through the system interface. There is no possibility that a malicious Skype binary can access files from another app without the user's interaction, am I right? You call it "largest possible access", I call it "restricted access", but that is just points of view. – Federico Poloni Mar 17 '20 at 14:54
@FedericoPoloni In Android, there is no possibility that any user installed app can access files from any other app at all, that's just how the system works. In the end, for the use case that Skype needs to serve, restricting its access to file system will restrict the files that the user will be able to send, just that. – bracco23 Mar 17 '20 at 14:58
4

@Bracco23 There's a difference between an app asking the user to select a file they want and only getting access to that specific file (which is what Skype needs) and the app having unlimited access to all the files in itself (something that skype really doesn't require). As I understand it, Android skype is the former, while desktop Skype is the latter. – Voo Mar 17 '20 at 16:47
@Voo but if you want to provide an app which can only access "shared" files, there needs to be an API-Layer in the system and a selection dialog, which the app can use - and the whole process needs to be accepted by enough users as comfortable enough to be widely used. Since Snaps are just catching on, it will probably take some rewrites in Skype to use these new APIs and a second code-base with the old code to run on systems without these new APIs, so additional maintanence cost and source for bugs or vulnerabilities. – Falco Mar 18 '20 at 12:55
1

@Falco Absolutely. i'm just saying that the argument "skype needs arbitrary files, therefore it has to have access to the whole filesystem" doesn't hold. – Voo Mar 18 '20 at 13:20
@Voo you are right. A better formulation would be "Skype needs access convenient and on demand to any file you specify" - And on all traditional systems this meant skype can theoretically access all user files, but we trust it will only read files which the users select in an internal dialog. New options just emerged - Android 10 is the first Android which experiments with a new API to make this possible - before any app which needed access to files had access to all your general files (not internal files of other apps) – Falco Mar 18 '20 at 13:58
@Falco Agreed, that's a good summary. – Voo Mar 18 '20 at 14:08
1

@Falco, flatpak has that API quite long and it is a freedesktop standard. Snap has no excuse not to use it. – Jan Hudec Mar 18 '20 at 20:49

score 15 · Answer 2 · edited Mar 17 '20 at 18:59

15

It’s like this comic:

Generally, any program that runs under your account can access any resources that your account can access.

Can Skype really scan anything I have in my home directory regardless of the permissions set to files and directories? Does it become like a sort of superuser?

As stated in MechMK1’s answer, no, it does not become more privileged than you. But, even if you chmod a file to 0, as long as you still own the file, any program (running under your user ID) can chmod it back to a more permissive access mode.

In general, it can do anything that malware can do if it runs on your system as you. For example, it can

modify your .bashrc, .bash_profile, or similar file to start it (or a component of it) every time you login.
monitor your keystrokes (subject to constraints that are beyond the scope of this question).
maybe read your screen (?)

How is it possible for an average "power user" to confine such an unconfined application?

If you’re paranoid that Skype (or any other program) is malware, but you want to run it anyway, there are some things you can do to protect yourself (and your data). In (roughly) decreasing order of security:

As suggested by Benjamin, isolate the untrusted software in some sort of jail, sandbox, container or virtual machine.
- Depending on how paranoid you are, you could have one isolation area for all untrusted software, or one for each untrusted program.
As suggested by MechMK1, create another user (with a different UID) for the untrusted software, and always run the software as that user (with sudo or su, or by logging in as the other user in another virtual terminal).
- Again, you could create one such user for all untrusted software, or one user for each untrusted program.
Create a separate user account for your most sensitive data.
This is pretty much the same as the above bullet, but looking at it from the opposite direction.
Encrypt your most sensitive data. This is the least secure of these options, as
- it does not prevent the software from deleting or overwriting your files, and
- as long as untrusted software is running as you, it can probably monitor a lot of your actions, and possibly read your data when you decrypt it to work with it.

None of the above is guaranteed.

Getting back to this:

Does it become like a sort of superuser?

For completeness, a program (that can run unconfined) can become privileged in the usual ways:

It can invoke sudo or su and hope you type the password. (Advice: Don’t do that!)
It can invoke sudo or su and try to guess the password.
It can invoke sudo and hope that you used sudo within the past five minutes, so your credentials are still cached (see the Sudoers Manual).
It can exploit a privilege-escalation vulnerability in the operating system.

etc. The confinement procedures discussed above can mitigate some of these attacks.

edited Mar 17 '20 at 18:59

XavierStuvw

965
2
8
15

answered Mar 17 '20 at 05:11

Scott - Слава Україні

297
1
10

Err, if it requires admin rights to install, then your "Create a separate user account for your most sensitive data" option is utterly useless because any admin account can gain access to any other account. – user21820 Mar 18 '20 at 06:10
That's precisely what *snaps* are supposed to change… except they did not enforce it from the start so there are still too many apps that are not appropriately confined. – Jan Hudec Mar 18 '20 at 20:44
@user21820: Well, sure, if you download a black box binary executable program that says “I’m the Skype installer; run me (unconfined) as root”, it’s like finding an opaque bottle labeled “Drink me” — either you [trust it blindly](https://fossbytes.com/10-immutable-laws) or you throw it away. (Or you do forensic analysis to assess its safety.) But if the installer is a script that says `install --owner=bin --group=bin --mode=755 ./skype /bin/skype`, then there’s no problem running as “admin”. (Of course `--owner=root --mode=4755` is a horse of a different color.) … (Cont’d) – Scott - Слава Україні Mar 20 '20 at 00:30
(Cont’d) … Aside from the fact that you arbitrarily singled out a sentence from my answer, your comment would have been more suitable for the question itself (‘‘Does it become like a sort of superuser?’’).   But it’s rather trivial that, if you run a program as superuser, then it runs as superuser. – Scott - Слава Україні Mar 20 '20 at 00:30
@Scott: I think you missed my point. My point is that **almost all** applications that the average user intends to install are executables that demand maximum rights. So that particular sentence of your post is bad advice for the average user, and hence I singled it out. Don't forget that users who can distinguish between the kinds of installers you mentioned in your comment mostly do not even need to read your post, and users who cannot are likely to come away from your post with the misconception that having separate accounts is sufficient. – user21820 Mar 20 '20 at 08:26
Also, your last comment seems misleading. Many programs cannot be installed without admin rights because they install some drivers or services, but are not run as superuser. Even if the program that is initially installed is clean, it may schedule an admin process to always run on start-up, thus providing a possible future superuser level threat. For instance, if the admin process does automatic updates, and a future update is malicious, the user would lose all security even though the original installed application was clean and the user did nothing. – user21820 Mar 20 '20 at 08:31
Note that this also nullifies your suggestion of "do forensic analysis to assess its safety", because that is quite impossible for applications with auto-update. And this isn't some nebulous threat. One browser that I won't name had their servers hacked recently and some versions replaced with malware-dropping copies. – user21820 Mar 20 '20 at 08:34
@user21820: OK, I see your point. (CCleaner is another well-known example of a program that auto-downloaded and installed malicious updates.) But why focus on my third bullet? “create another user for the untrusted software” is equally pointless. And, if you’re dealing with a rootkit, it can compromise all your decryption software, so it can trivially exfiltrate your data when you decrypt it to work with it. … … … … … … … … … … … … … … … … … … … … … It seems to me that you have enough to say about this question that you should post your own answer. – Scott - Слава Україні Mar 20 '20 at 23:37
@Scott: The reason I'm not posting an answer is because I don't disagree with most of what you and the other answerer have said. Except, you know, for one point; that is why I'm commenting. =) Anyway, to clarify why that point is different from the previous one: If you tell a lay user to install applications only as limited user and never as superuser, the threat will not be there. However, the point that I critiqued seemed to suggest that it is equivalent if you switch around the users, and in my experience many lay users do not understand that it's very different. – user21820 Mar 21 '20 at 03:19