For the future I think it would be nice if you could install security updates without installing the other updates from software center.
At the moment I would say it is ok if the single security update could be installed at the command line. If this is possible, you could post a short howto and inform everybody about it per pm.
3 Likes
We don’t have minor version branches. There’s a single repository version, that is “7”. Since monday we reached (say) milestone 7.4. But the latest 7.3 is almost equal to the first 7.4: it’s a continuum, rolling release.
In short the question is
What to do on systems that are not updated to the latest version?
The fix can be installed on any ns7 updated to September 8. That day we released another important security fix (CSRF token) and any subsequent update must include it to avoid breaking dependencies.
So the solution for non-updated systems is to cherry-pick the fix with
yum localinstall http://....
I agree, and we have also the solution, I think: the Stephan’s contrib, based on yum-cron!
3 Likes
IMO, if the bug is discovered and not published
-
develop and QA fix without disclosing anything
-
notify community about a security fix incoming, without spreading panic or giving any details about vulnerability
-
wait a few time
-
release fix and backports
-
Notify community about security fix, affected version and fixed version. I’d also like auto-update and server-manager notifications
-
wait some days or weeks (no hurry here)
-
Full Disclosure
-
credits and bounty
In case of a 0-day, skip 2. 3. and 8.
5 Likes
Do I understand correctly that it will be possible to cherrypick updates this way? Like you have in the MS world with WSUS? (I would love to have such a feature!)
1 Like
Yes but to make it work we (developers) must add some metadata to our releases…
4 Likes
Great!
And having (consistent) metadata is always a good idea… 
3 Likes
I think we are now at step 5 and we can improve the Server Manager with these features in the future. By now one can install yum-cron (but we must implement required metadata to make it work properly with our repositories, whilst upstream are ok).
My proposal is now to wait the 7.4 release announcement, that will be likely Monday, Oct 30 (@alefattorini is working on it).
Then we can publish an advisory, with the information I already shared here.
A few days after that, we can fully disclose the issue - and tell the nice story behind that 
7 Likes
I to love the idea!
1 Like
Thank you for the update…appreciate the solution too…Well Done !
Testing updates before releasing them is so critical it should be top priority number one 
Another system i am (was) using didn’t do that properly.
It made my system unbootable ! That is unacceptable.
And now I’m supposed to debug their custom debian stuff to find the problem ? No thanks 
We have Nethserver and it’s rock solid
Please keep testing the updates as much as possible.
1 Like
Alert … opinion ahead
I am a firm believer that security notices should be released as soon as a fix is ready or it’s (the flaw) wide use is anticipated. We rely on you guys to supply accurate and detailed information about the threat as soon as possible so that we can determine the impact and act accordingly.
Any sysadmin not following DTAP is asking for problems and any sysadmin who doesnt make time for security deserves them. So please, make sure security updates do not break a system as much as possible, but do not hesitate too much in informing those of us who covered their bases appropriately. Any sysadmin claiming DTAP is too costly should try a 1tb harddisk and VirtualBox on just about any client hardware.
Run that update on a similarly configured install and check if it survives is not hard nor time consuming … it just requires some commitment to follow through.
This would work, unless the security threat is a major one, in which case I rather know it now, and be forced to disconnect my server from internet to mend the issue, then to exist in ignorance while script kiddies are abusing a 0-day which fix is being QA-ed …
1 Like
agreed, though IMO you should be able to mitigate most of those using fail2ban and a solid IPS/firewall configuration as well as monitoring. You can also mitigate some risk by going through centos and hardening yourself to your satisfaction. I cant say 100% my network is safe, no one ever can, but I am confident that it is as reasonably safe as I can make it, port scans are auto block in shorewall, vulnerability scans same, ddos and any form of probing is immediately blocked perm, beyond that the only way you might be in trouble is IF there is a 0-day floating out there and IF someone targets you personally, and IF they dont get banned on the at least 3 different nets protecting RED interface. I am also geoblocking, so countries that are known for basement script kiddies (russia, china, north korea) are blocked as a country. Best thing for you is to know your network, know your security, know what you are dropping and know how to spot anomalies.
I agree, but that is a tall order for most organisations, given their state. A firewall won’t help you with a 0-day on any of your services
Well, yes it would to a certain degree. 0-day doesn’t matter if you drop the packet. Shorewall blocks everything by default and only allows a couple things. I always set httpd admin to green only (default is red/green), and cockpit/ssh as well. If you need access to any of that, vpn in. Change VPN port, change SSH port. Its all isolated as well. Set a good admin pass and even if someone “breaks” in on 1194(vpn) or smtp/imap, still cant do anything. Plus we get security updates from centos repos. The gateway isnt the problem, its not managing users behind the gateway properly. Almost every breach today comes from users giving info/not being educated properly. If a user downloads malware that accesses server information, thats not the servers fault thats the local admin not doing his job in regards to locking users down and social engineering training. Just my 2c
2 Likes
Agreed … I usually neglect to name common sense. I meant a 0-day on an open service. It goes without saying, to me, that you do not open ports that do not absolutely need to be open. But yeah, that’s not intuitive to everybody, so thanks for making this point.