Stop supporting OSes that don't support themselves

[jay0lee]

Currently GAM runs on:

Windows 7 (maybe even Windows XP still?)
MacOS 10.12 Sierra
Ubuntu 12.04

these operating systems are no longer receiving updates from their vendors. This leaves them vulnerable to hacking.

GAM is an extremely powerful application that has direct access to perform G Suite admin actions and access end user data including mail, calendar and drive files.

For the safety and security of GAM users (and their organizations and users), GAM should require the admin to run on an OS that is receiving (at least) security updates from it's vendor.

Steps that can be taken now:

• Stop building GAM on MacOS 10.12 Sierra
• Stop building GAM on Ubuntu 12.04

TBD:

• Can GAM detect if it's running on an abandon OS version and either refuse to run or nag the user to upgrade? This will likely be necessary for Windows and the legacy Linux build since they offer compatibility to very old OS versions.
• Can GAM warn a user if the OS they are running is approaching vendor abandonment? (e.g. MacOS 10.13 will EoL in Sept, warn users to consider upgrading now.

@taers232c FYI, I'd recommend your GAM versions perform similar actions, while we generally strive to make GAM run everywhere compatibility should not take a higher priority than security.

[jay0lee]

I just realized Ubuntu 14.04 Trusty is EOL also. Working to get it removed from builds.

[ghost]

IMO it's not the application's place to tell the user where to run it. If the user is running an EOL OS then these are issues that GAM is both unable and unsuitable to try and fix.

In particular, this sort of custom behavior also impedes the ability of GAM to adopt a more standard packaging approach (such as a setup.py as noted in #1140).

[ghost]

To clarify, I of course am not saying that the application should support every OS version there is - GAM certainly must define a minimum requirement. However, it's not within the scope of the application to manage complaints about the OS environment within the application itself. By utilizing e.g. setuptools to standardize the installation, you can specify the python requirements, which is what GAM should be managing. If the user is using an outdated OS but with updated Python libs/dependencies, then the user either has a reason for doing so or has much bigger problems than GAM can possibly hope to fix.

[jay0lee]

Agreed that it's not the apps job but it is an apps duty to report obvious, egregious security issues where it can.

GAM won't be able to go so far as confirming the OS has the latest patches or in the case of Linux, even confirming it's not EOL (unlike Windows and MacOS, there's no central authority on which distro vesions are EOL). However where we see obvious issues here we can provide guidance to the admin that if followed will improve their security posture.

None of this work should interfere with setup.py / pip-installable work though in some cases such as installing GAM on a very old version of Linux (that somehow has a modern enough Python) the install may succeed but GAM warn the user about old versions.

FYI I intend to have this work similar to how the check for GAM updates currently works. If an old OS is found then GAM will warn the user but the user can always override by creating a file like nooscheck.txt.

[ghost]

There's a fundamental issue of GAM overstepping its bounds. GAM is a useful tool, like ls or vim. Imagine if all of these tools had their own OS checker, update checker, and custom installers. It'd be pure madness! GAM need only worry about creating installations that are common to the Python ecosystem (e.g. setuptools) and then work on improving the program itself. Anything more than than and it's an unwise use of time at best and an unmaintainable security problem at worst.

[jay0lee]

Thanks for the input @zingyb but I think we'll just disagree here.

[9072997]

Extended security updates for Windows 7 last until 2023. Should GAM run on a computer running Windows 10 if it doesn't have the latest security updates? What if it is missing a patch that allows remote code execution, but that patch has only existed for one day? The situation gets even more complex on Linux where OS version is a generalization. What if you are running Ubuntu with some packages from 14.04 and some packages from 16.04? What if you are running under OpenVZ where your kernel version does not match your VM's OS version? What about chroots?

[steviefaux]

You can give a warning to a user but surely it shouldn't be up to GAM to decide when a user needs to upgrade.

Besides, and I could be wrong, but GAM has had (not tried it since) a big flaw for years. I mentioned this at work years ago but nothing was ever done.

Once GAM is setup on a users machine their account is now essentially fulnerable. If anyone is able to get on that machine and copy the GAM folder to their machine. They now have full admin access to do as they wish with that account via GAM and never need to actually know what the users password is. I did a video about this a few years back.

[daethnir]

Gam should not try to guess what is or is not a supported operating system.

Plebean support for windows 7 is long gone, but many big companies can get MS to support it for years afterwards. Ubuntu's LTS releases expire, but you can pay them for extended security maintenance in which case you are still getting patched.

Gam would have no idea which case you fall into, so it shouldn't bother trying. All it should care is can it run, e.g. are the packages it needs available.