A possible solution for automatic security updates

[Rehdon]

While I agree with Clem that this is basically a storm in a teapot, and a wasted day of work on the latest RC, I realized that there actually is a security "problem" for Linux Mint security updates. Let me explain: what I've done so far was to apply all the level 1-3 updates, let the kernel, X11 and other critical updates wait a little in queue, then apply those as well with Synaptic. I always did this just out of precaution, because I've been bitten by a bad update in the past, and the end result is the best of both worlds, as Clem probably intended. In the end, all security updates are installed on my boxes.

Note, however, that I also installed LM for my son, who is not Linux savvy; and for a co-worker of mine, who likewise has little to no experience with Linux. I imagine that many of us have done it for friends, relatives, etc. Now, the end result is that critical security updates are never applied on those systems (unless I step by and do it, that is) and this certainly can't be seen as a good thing, or dismissed altogether as a "but you can do that by other means": sensible defaults, one of LM strong selling points, matter all the more in this case because there are users who will never modify them, or look for alternatives to them.

If we want LM to be a suitable for all distro, this problem has to be solved. The only way to do that that I could think of is to make the whole process semi-automatic and community-driven, i.e.:

- at first critical updates are tagged as 4-5 updates and hidden to the user;
- more experienced users install them and report on a specific forum section (or on Segfault, or any other appropriate location); by report I mean "It works for me on this hardware: X Y Z" (with proper and longer reports if/when there are problems);
- the devs also raise their antennas about possible problems on Ubuntu systems (they can be our guinea pigs, no offense meant
- when there have been enough positive reports and no problems have popped up, the packages are bumped to 1-3 level, so that all users will install them.

What do you think? I believe the LM community can make this a straightforward process.

Rehdon

[xenopeek]

Moved here as this isn't a support request.

Most security fixes are for packages other than the Linux kernel or the X.org server. You can review Ubuntu's security notices here: http://www.ubuntu.com/usn/. Those that are about the Linux kernel or the X.org server don't immediately or necessarily translate to being a security issue for you. Many of the security issues are highly specific, being applicable only to users with specific hardware or peripheral devices or users using specific kernel functions. I don't think there is an issue with using Update Manager in the default configuration. For average users the Ubuntu security notices probably seem daunting, though I think it is the best way to evaluate whether you need to do an upgrade or not.

Perhaps to improve your idea: I think it will be useful to define a minimum set of test cases that should be met (and so have been tested) for each kernel upgrade. Things like testing it with open source drivers for AMD and Nvidia cards, and with specific versions of the closed source drivers, and for those tests to have been done at least on Cinnamon and confirming after upgrade there wasn't a fall back to software rendering. There are undoubtedly other clearly definable cases that often cause problems with kernel upgrades.

To my mind, the community could already implement all of the steps of your idea--expect the last step would be manual. It just needs other members involved to test a new kernel and report back on it for specific hardware. This could be organized by posting a new topic when a new kernel upgrade becomes available, those involved with testing commenting there, and other members taking their cue from that topic on when they are good to go on doing the upgrade. I'd prefer such a scenario for now, so that users that do run into problems immediately have a place to ask for support.

[cryogenic88]

Im unsure what the big deal is with level 4 and 5 anyway. Even if you install everything the base risk of breakage is the same as a Ubuntu install with the same repos enabled (ie. not much), or perhaps a little bit higher in the unlikely event that something messes with the mint-specific stuff.

[Rehdon]

Most security fixes are for packages other than the Linux kernel or the X.org server. You can review Ubuntu's security notices here: http://www.ubuntu.com/usn/. Those that are about the Linux kernel or the X.org server don't immediately or necessarily translate to being a security issue for you. Many of the security issues are highly specific, being applicable only to users with specific hardware or peripheral devices or users using specific kernel functions. I don't think there is an issue with using Update Manager in the default configuration. For average users the Ubuntu security notices probably seem daunting, though I think it is the best way to evaluate whether you need to do an upgrade or not.

The issue is the one I described in my original post: less experienced users will not install some of the updates, ever, because they won't even know about them; and I didn't know about the site you quoted, it's high unlikely that the users I'm thinking of do either. Saying that they may be unnecessary because most of them are applicable to specific configurations is like crossing your fingers and hoping for the best: an unacceptable security policy for any distribution aiming at being taken seriously. This is a real problem that has to be addressed if we want Linux Mint to be a distro that can be recommended to everybody.

Perhaps to improve your idea: I think it will be useful to define a minimum set of test cases that should be met (and so have been tested) for each kernel upgrade. Things like testing it with open source drivers for AMD and Nvidia cards, and with specific versions of the closed source drivers, and for those tests to have been done at least on Cinnamon and confirming after upgrade there wasn't a fall back to software rendering. There are undoubtedly other clearly definable cases that often cause problems with kernel upgrades.

To my mind, the community could already implement all of the steps of your idea--expect the last step would be manual. It just needs other members involved to test a new kernel and report back on it for specific hardware. This could be organized by posting a new topic when a new kernel upgrade becomes available, those involved with testing commenting there, and other members taking their cue from that topic on when they are good to go on doing the upgrade. I'd prefer such a scenario for now, so that users that do run into problems immediately have a place to ask for support.

That sounds good to me and yes, I was fully conscious that the last step has to be manual: there must be some "authority" who scans the reports and decides if a security update is "safe enough" to be pushed to all users.

Rehdon

[tracyanne]

This is a huge problem as far as I am concerned. I install about 1 Linux based system a month, many of those are Linux Mint (some Ubuntu, some others like Zorin and Pear). The fact that updates cannot be scheduled to occur automatically in Mint is a huge risk I have to take with most/all of the people I install Linux Mint Systems for.

In general these people don't want/can't deal with strong passwords, which I insist on for root access. In general they are also not the sort of people who will install new software, once the computer has been configured to their needs, so a strong password is not really an issue.... except if the system needs to have updates applied, it IS needed. Which means these people will either never get the needed security updates or they will have to ask me to do it, neither of which is acceptable in the long term.

If it is never possible to set Linux Mint Systems to automatically update, Linux Mint will NEVER be considered user friendly or acceptable as an operating system for the sorts of people who would actually benefit from a Linux based system.

So while this may be a strom in a teacup, as far as Clem and other Uber geeks are concerned, it is a very real security issue that needs to be addressed, if Linux Mint is to be anything other than a geek toy.

[monkeyboy]

When considering the relevance of a problem one must factor in both the severity and the likelihood of its occurrence. For example getting hit by a car while crossing the street can get you killed but most everyone still cross streets because the rate of occurrence is so low.
For a particular security problems its the same thing to me, if I get had it sucks but how many people have actually taken it in the neck under the current situation? I for one have never been had a problem while using Mint over the last few years so for me its not a problem. So I guess my question is how many folks have had a real verifiable problem and how many haven't?

[xenopeek]

The fact that updates cannot be scheduled to occur automatically in Mint is a huge risk I have to take with most/all of the people I install Linux Mint Systems for.

The fact is that you can of course schedule security upgrades to be done automatically. That's what unattended-upgrades is for... It's a trivial thing to set up for anybody with a little command line experience. Here is a short guide: http://linuxaria.com/article/enable-automatic-security-update-in-debianubuntu?lang=en

[tracyanne]

Thanks xenopeek, I wasn't aware of these config settings. unattended-upgrades is already installed on my machines, so it's probably already installed on recent LM installs I've done. I'll try that out on one of my machines, If I'm happy with that I can apply it to other Linux Mint installs, and to a few of my recent customers.

[foobiebletch]

I am in a similar situation with a relative's computer for which I want the available updates to run. For the Allowed-Origins section of /etc/apt/apt.conf.d/50unattended-upgrades, I used the following:

Code: Select all

Unattended-Upgrade::Allowed-Origins {
//      "${distro_id}:${distro_codename}-security";
//      "${distro_id}:${distro_codename}-updates";
//      "${distro_id}:${distro_codename}-proposed";
//      "${distro_id}:${distro_codename}-backports";
        "linuxmint:qiana";
        "Ubuntu:trusty-security";
        "Ubuntu:trusty-updates";
        "Google\, Inc.:stable";
        "Canonical:trusty";
};

The above configuration seems to be automatically updating the Qiana packages, the upstream security and distribution updates from Ubuntu, Google Chrome, and the Canonical partner repository. Of course you also have to set Unattended-Update to 1 in /etc/apt/apt.conf.d/10periodic:

Code: Select all

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Download-Upgradeable-Packages "0";
APT::Periodic::AutocleanInterval "30";
APT::Periodic::Unattended-Upgrade "1";